@girish said in Backup size: Thanks, I deleted files in the Nextcloud recycle bin. Now, after a reboot, Cloudron System Info shows 4.3 GB for the Nextcloud instance. (I had to delete the nginx config of a stopped app to get the system to reboot.) Thanks, I'll keep both folders. I have no particular goal to remove Discourse or its backups. I measured /var/backups size by adding up the three separate folders that FileZilla showed me, but I now understand that some files are hardlinks. And the Backup data shows only 4.87 GB now, so my disk is small enough for me to move on. Thank you!

I created a new SMTP user and used that in the second Cloudron. Worked like a charm. Thanks!

@girish I just tried a free VPN service and the domain loaded but on the other computer without a VPN it did not load so I am thinking it is a problem with my ISP. I'll let you know how I make out with it.

@scooke I went to each individual app and pointed to the fileshare with the full path "/media/fileshare/2020-07-01-0500/app_backup.tar.gz.enc" and restored those backups. As for the second part, Azure adds the following "actimeo=30" switch to the cifs share that goes in your /etc/fstab file that causes the connection to time out if the backup takes too long. Once that is removed, reboot the server and the new backups will complete without issues.

@Mastadamus yes, reverse proxy is implemented in next release (7.3) - https://forum.cloudron.io/topic/6655/what-s-coming-in-7-3/21

@zylstra right, we removed the version in the default footer.

@nebulon Per https://docs.microsoft.com/en-us/windows/win32/adschema/a-userprincipalname , it's an email address and not a username. Also, see https://ldapwiki.com/wiki/UserPrincipalName which sometimes says email and sometimes username. @colonelpanic Do you know what your software expects this to be?

The doc actually says "The Backup Cleaner checks if entries in the database exist in the storage backend and removes stale entries from the database automatically." I will fix the progress message to match this.

@humptydumpty Thank you, that has actually worked!

Thank you, @nebulon and @scooke! After deleting the backups, checking various services, and restarting a number of times, everything is back. Thank you again!

gosh, i only changed the language in the settings. needed to go to the user profile and made the switch. no wonder why thanks guys!

@girish So after the upgrade to 7.2.2 the problem vanished. Closing the Ticket. Thank you for the help!

@Lizzit right most likely this is the case, especially since it is hard for a system like Cloudron to correctly detect and fixup already made changes or package installations to fit its need for a stable update-able system. To maybe say this in advance, also after having installed Cloudron, it is not supported to install other things on the side, as it will eventually break on updates in our experience. Note that Cloudron is aiming for reducing the technical complexity for selfhosting and reduce time to maintain it, which requires some more stricter control of the system as such and we have decided on that route, since with the affordability of virtual servers it is likely much easier to just get a fresh Ubuntu rather than trying to debug configurations on updates.

@necrevistonnezr said in Nextcloud App "not responding" after upgrading to Ubuntu 22.04: EDIT: I guess that replacement should go into /home/yellowtent/box/src/infra_version.js - but after a restart of box, still not running... Yes, that's the correct place to fix it! I will add a warning to our docs that updating to ubuntu 22 when using FTS feature does not work out of the box / without patching until 7.3.

@humptydumpty I think not - https://askubuntu.com/questions/844689/instance-with-canonical-livepatch-service-requires-restart

@girish The MX record resolves to an ISPs server (Strato): smtpin.rzone.de But I don't know if this is particular timeout is domain specific or applies to all of strato. I'm worried it might be the former, at least protocol wise at the point of the delay the recipient domain is known and the server could apply domain specific settings for the backoff/delay.

@tuejon What you could do is setup proxmox an run 2 virtual machines on your server. One with cloudron one with whatever you want to do.

@girish Ah I didn't see this until too late, sorry. I had tried to start over to a degree by destroying the current backup disk and mounting a new disk instead then clearing out the backups history and seeing if that starts working better for me. So far so good, but if the issue comes back I'll certainly send the email out and enable remote support, as I agree there seems like some odd issue for sure.

@Dreamcatch22 I am fixing the docs to add the resolution of the other thread. About the "unable to resolve host" issue, that is just a warning. But to fix it, you have to make sure that your server's hostname (/etc/hostname) has an entry in the /etc/hosts . See https://askubuntu.com/questions/59458/error-message-sudo-unable-to-resolve-host-none for example on how to fix that.

@girish thank you! And thank you again for your prompt help!