Cloudron Forum

Update: I restarted the updates as I had noted there were some more, and after catching up the app works fine.

what features does / will it have that sogo is missing? will the calendar have a easy to understand out of office?

Vendor: System manufacturer Product: System Product Name
Linux: 5.15.0-179-generic
Ubuntu: jammy 22.04
Cloudron: 9.2.0
Execution environment: none
none
Processor: Intel(R) Xeon(R) CPU E3-1225 v6 @ 3.30GHz x 4
RAM: 32807988KB
Disk: /dev/nvme0n1p2  697G
[OK]    Root disk usage is OK (22%)
[OK]    Memory usage is OK (46%)
[OK]    Clock is NTP-synchronized
[OK]    node version is correct
[OK]    IPv6 is enabled in kernel. Public IPv6 address detected
[OK]    docker is running
[OK]    docker version is correct
[OK]    MySQL is running
[OK]    netplan is good
[OK]    DNS is resolving via systemd-resolved
[OK]    unbound is running
[OK]    IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[OK]    IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[OK]    IPv4 HTTPS to auth.docker.io/token
[OK]    IPv6 HTTPS to auth.docker.io/token
[OK]    IPv4 HTTPS to acme-v02.api.letsencrypt.org
[OK]    IPv6 HTTPS to acme-v02.api.letsencrypt.org
[OK]    nginx is running
[OK]    dashboard cert is valid
[OK]    dashboard is reachable via loopback
[OK]    No pending database migrations
[OK]    Service 'mysql' is running and healthy
[OK]    Service 'postgresql' is running and healthy
[OK]    Service 'mongodb' is running and healthy
[OK]    Service 'mail' is running and healthy
[OK]    Service 'graphite' is running and healthy
[OK]    Service 'sftp' is running and healthy
[OK]    box v9.2.0 is running
[OK]    Dashboard is reachable via IPv4 (https://my.rotovegas.nz)
[OK]    Dashboard is reachable via IPv6 (https://my.rotovegas.nz)
[SKIP]  Domain expiry check — whois did not return an expiry date for rotovegas.nz

======== Summary ========
PASS:  30
WARN:  0
FAIL:  0
SKIP:  1

Working version : Invoice Ninja 5.13.22

I tried a restart, no change, I hadn't used it since the last backup so I have restored to then, and it works again.
I have disabled automatic updates for now.

Get this error

Error :: to 'BuiltMap<String, int>' failed due to: Deserializing to 'int' failed due to: type 'List<Object?>' is not a subtype of type 'int' in type cast

I have no understanding of what that means.

Not sure exactly the cause, however the app being backed up was peertube, and a update was scheduled and failed around the same time. The fix was deleting the corrupt file in the snapshot folder on my truenas from shell. Then re-running the backup

Heres the snip of the error log...

May 26 23:00:44 backupformat/tgz: Attempt 3 failed. Will retry: tarPack pipeline error: ENOENT: no such file or directory, open '/mnt/cloudronbackup/snapshot/app_10da5f93-af48-4972-ae9d-4f416962d3ee.tar.gz' 
May 26 23:01:04 tasks: updating task 11012 with: {"percent":9.695652173913043,"message":"Uploading backup snapshot/app_10da5f93-af48-4972-ae9d-4f416962d3ee.tar.gz (peer.rotovegas.nz)"}
May 26 23:01:04 backupformat/tgz: addToPack: error adding ./dump.rdb file ENOENT: no such file or directory, open '/mnt/cloudronbackup/snapshot/app_10da5f93-af48-4972-ae9d-4f416962d3ee.tar.gz'
May 26 23:01:04 backupformat/tgz: BoxError: ENOENT: no such file or directory, open '/mnt/cloudronbackup/snapshot/app_10da5f93-af48-4972-ae9d-4f416962d3ee.tar.gz'
    at file:///home/yellowtent/box/src/backupformat/tgz.js:67:24
    at Sink._continuePack (/home/yellowtent/box/node_modules/tar-stream/pack.js:42:5)
    at Sink._destroy (/home/yellowtent/box/node_modules/tar-stream/pack.js:121:10)
    at WritableState.updateNonPrimary (/home/yellowtent/box/node_modules/streamx/index.js:213:16)
    at WritableState.update (/home/yellowtent/box/node_modules/streamx/index.js:195:72)
    at WritableState.updateWriteNT (/home/yellowtent/box/node_modules/streamx/index.js:564:10)
    at node:internal/process/task_queues:149:7
    at AsyncResource.runInAsyncScope (node:async_hooks:214:14)
    at AsyncResource.runMicrotask (node:internal/process/task_queues:146:8)
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5) {
  reason: 'FileSystem Error',
  details: {}
}
May 26 23:01:04 backupformat/tgz: tarPack: packed 0 files
May 26 23:01:04 backupformat/tgz: Attempt 4 failed. Will retry: tarPack pipeline error: ENOENT: no such file or directory, open '/mnt/cloudronbackup/snapshot/app_10da5f93-af48-4972-ae9d-4f416962d3ee.tar.gz' 
May 26 23:01:04 backupformat/tgz: [Error: ENOENT: no such file or directory, open '/mnt/cloudronbackup/snapshot/app_10da5f93-af48-4972-ae9d-4f416962d3ee.tar.gz'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/mnt/cloudronbackup/snapshot/app_10da5f93-af48-4972-ae9d-4f416962d3ee.tar.gz'
}
May 26 23:01:24 tasks: updating task 11012 with: {"percent":9.695652173913043,"message":"Uploading backup snapshot/app_10da5f93-af48-4972-ae9d-4f416962d3ee.tar.gz (peer.rotovegas.nz)"}
May 26 23:01:24 backupformat/tgz: BoxError: Failed to add ./dump.rdb: already finalized or destroyed
    at file:///home/yellowtent/box/src/backupformat/tgz.js:73:39
    at new Promise (<anonymous>)
    at addEntryToPack (file:///home/yellowtent/box/src/backupformat/tgz.js:63:12)
    at addPathToPack (file:///home/yellowtent/box/src/backupformat/tgz.js:110:23) {
  reason: 'FileSystem Error',
  details: {}

to me it reads like its blaming the truenas destination, but the truenas reports no problems. and the file app_10da5.... is 9Gb and created on the 24th May. Should I just delete the files in the snapshot folder and let it re-create them ?

Oh, dolphin also complains about the file not existing, when I try to open or delte it, so I gues its just corrupt. /case closed.

@nebulon Yeah, I got that wrong. pretty similar names & product.

https://office.eu/

Seems like more of the world is finding ways to escape tech giants.

yeah there is now... ok now its stopped. I cancelled the update (with backup) and ticked skip backup, the update went fine.
Thanks!

I suspect its because i turned off its automatic backups, as they appeared to include all the hosted data, which was over 600GB.
Is there a way to make an update apply without backing up ?

Assuming this works, when the vibe coded unsecure app you found on github installs into cloudron, and is exposed to the internet does cloudron support still offer help or laugh at your self inflicted hole in foot?

@humptydumpty I don't think its plays nice with wayland, but I have had it running on a X11 Manjaro & mint installs for a couple years no issues at all. Also the console / shell is available much like an SSH session.

I'm not saying it will suit everyone but dwservice is a free and useful remote support solution. And you don't have to host anything.

https://github.com/minio/minio?tab=readme-ov-file

Whats the implication of that on its cloudron app ?

@nebulon Got a date in mind for the platform upgrade? the mobile is app, is janky / broken in its current state.

After some app update, I got a circle of doom please wait while indexing / hashing (a term I don't remember) ... ANyway it didn't ever finished and I restarted the phone for a different update. Opened immich again, & I had to reselect the "backup" folders with photos on my phone before they displayed again, and even then it only showed them as on local device, despite them being also on the server (confirmed via a web browser). mobile app seems a bit janky right now

No I didn't change any settings, just have automatic updates enabled, so thought that the updates had triggered the problem.
Yes thats correct, I'm not sure what the default setting is for email, and the only issue I can find is the health report error to do with queued jobs.

Did I do any other changes to get it working, or to break it ?
It was just failing to send invoices 1 september,
When I found the 404 error, and looked at the invoice ninja github, Ifound a similar issue logged by another user at the same time.
I found the other users attempt to run a php command to trigger the queue, which appeared to work in console, but made no difference to the health report screen. Also I added SCOUT_DRIVER=null to the env file.
It wasn't until I changed the email settings to use SMTP, and corrected the default email address of the admin account, to my actual address, that sending invoices again worked for me.

Because the default( which looked blank) stopped working, so I tried some other settings, because I needed to send invoices. otherwise I don't eat (lol).
Yes it works fine.