Just tried updating the CLI via npm install -g cloudron@8.2.1 and it seems to work now Thanks for looking into it.

This too might be related to the ubuntu kernel issue. Can you check the output of uname -nar ?

Hello @davejgreen This is rather complex backup set up which is out of scope of the nominal Cloudron use-case. @davejgreen said: I have added several entries to the /etc/hosts file on the new server to point all our Cloudron domains to its IPv4 and IPv6 addresses. This should be done on your local device so you can access the domain names without the DNS lookup but with a fixed entry overwriting DNS lookup. @davejgreen said: So, on the new server, I did mkdir -p /mnt/managedbackups/cloudron-restore-validation/nfs-tarballs/snapshot. I could then see the backups from our office device at /mnt/managedbackups/cloudron-restore-validation/nfs-tarballs on the new server. (How did they get there if all I did was make a directory?) I then did the chown as instructed and tried clicking "Restore" in the browser page again. This time I got the error: Failed to unmount existing mount Is this referring to a mount that was somehow made when I created the directory? Why does it need to unmount it, and why can't it do that? Do I need to unmount something? This is indeed strange. Did you configure the NFS mount on the new system manually? Can you run mount -l and see if this NFS mount is there? Also, if mounted, there might be a systemd service for that mnt-managedbackups.*. @davejgreen said: I tried the dry run restore by rsyncing the folder of tarballs from a recent backup onto the new server, and then using "Filesystem" as the storage provider (as mentioned in the docs). This means that the location was already filled with data? I would advise resetting the new server again and only attempting the dry run restore from NFS. The rsync of files to the same location might have caused issues with the mounting and access of files.

Hello @vk182 Great to read!

@james ls -l /home/yellowtent/platformdata/logs/syslog.sock srwxr-xr-x 1 yellowtent yellowtent 0 Apr 20 20:20 /home/yellowtent/platformdata/logs/syslog.sock

@tlem4 The dashboard issue is related to the latest ubuntu kernel having a regression. You are running 110 which has a bug . See https://forum.cloudron.io/topic/15265/unusable-application/39

Ok I did restore a previous state and then proceeded to update. This instance was not critical so no data loss

Hello @mendoksai That checks out with our other topic. A RAID failure can cause such a catastrophic issue.

From that error log it seems that other app is sqlite related: "[DB] INFO: Database Type: sqlite" Is this all related to the same rocket.chat app uninstall issue or some other problem? For mongodb not running, with latest Cloudron we stop unused services, so this sounds actually correct.

Needed to run cp /etc/docker/daemon.json /etc/docker/daemon.json.bak printf '{}\n' > /etc/docker/daemon.json systemctl restart docker systemctl status docker --no-pager As per the Hostinger AI, there were an issue aroundlog-driver in conflict

Thanks for the answer - I'll check until monday. Yes, I used AI but I personally checked and validated and understood the problem before posting.

@james Yes, this is a great find. Thanks a lot for your cooperation. In email service’s logs no any log... Whenever you want, I can reproduce issue and I can send you raw log. Keep me posted.

@imc67 So were we using the same rules from @d19dotca ? For now I removed from all istances, but in future I want to keep only rules who works in local, not requiring any outbound connection.

This is now fixed for the next release with https://git.cloudron.io/platform/box/-/commit/a4ea80cf5eb26b08462430111e8b6f75175e749d

@james said: I suspect that this might happen in the backup process and thus changing the amount of files. I think that's actually unlikely in this case because I'm pretty much the only active user of this instance and it backs up while I'm asleep. But I'll try to give enabling maintenance mode a try to see what we can see...

Ah, actually, I think it's likely just that my Firefox is glitching out as it's everywhere for me right now.

Similarly described in Unusable application: Pushing/pulling an image from a remote works correctly. However, attempting to pull an image from the same server doesn't work at all. I tried upgrading to Ubuntu 24.04 and it seems to work as expected now (versions file + icon on the same server without issue).

Glad you found the issue and thanks for sharing the fix.

Hello @hpz24 Glad to read this resolved your issue and sorry for the inconvenience.