Solution : In my case, /home/yellowtent was owned by root, gpg was trying to create "~/.gpg". My fix : "chown yellowtent:yellowtent /home/yellowtent/"

Upgrade went well - all good on v5.1.3 now

OK, I will try to reproduce it locally and reach out if required. Thanks!

THANK YOU. I use Cloudflare as my DNS provider. Looks like they have some sort of caching feature called Cloudflare Rocketloader which caused this conflict. I Turned it off and it worked now. Much appreciated! @nebulon https://community.cloudflare.com/t/how-can-i-remove-the-rocket-loader-script-from-the-header-tag-on-my-website/4229

The issue here was that @minhbaop imported a box backup (i.e a backup with box_ prefix) into an app. Cloudron clearly has a bug that importing an unknown format makes it put the app in some indeterminate state. We will get this fixed in some future release.

Hi, After reboot my vps, all seem work now. thanks for ur reply.

Agree, the memory graphs are quite rudimentary at this point. We will rework them to be more useful and correct at some point.

Finally, one important bit: by default ext4 will reserve 5% of the disk for the root user. You can see this like so: root@strawberry:~# tune2fs -l /dev/sda1 | grep Reserved Reserved block count: 1562918 Reserved GDT blocks: 1024 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) 1562918 blocks * 4096 block size = ~6GB. You can reduce the percent to say 2 like this: tune2fs -m 2 /dev/sda1 Unless you have a big disk, I would leave it at 5%.

I remember some cleanup features in the unattended-upgrades package.

Maybe one specific file name/path which just happens to be produced by rainloop causes CIFS to fail?

@girish Unfortunately I have a different issue when running non-encrypted, which is posted here: https://forum.cloudron.io/topic/2270/backup-issue-in-rsync-non-encrypted-filesystem-type-never-moves-past-status-of-removing-directory-for-one-particular-app

Thanks @girish!

@avatar1024 Thanks, I have put a note in our doc for now. We will try to put a note in the UI as well for next release - https://cloudron.io/documentation/user-management/#administrator Also, users appearing in the app itself relies on LDAP sync which the app may or may not support. (This is why, just for consistency, we simply tell people to make sure users login to the app first.)

For discourse, we found that it doesn't have proper LDAP support yet. Please see https://forum.cloudron.io/topic/2/discourse/20 . If a plugin comes up, we are happy to integrate it into the package.

Thanks for reporting, this has been fixed now and will be part of the next release.

@girish I'm always amazed at how quick you guys on these things, thanks for fixing that so soon!

The recommended way is what @murgero suggested. Access via the dashboard. The console/terminal gives you a sandbox access to the app. At the server level, if you are curious, I can explain a bit. root@localhost:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d9fa2018bc0c cloudron/org.wordpress.cloudronapp:20200212-180328-807b9bf4d "/app/pkg/start.sh" 15 hours ago Up 15 hours 127.0.0.1:36813->8000/tcp fe672d3d-d2c2-472e-a46b-a6dda9bb1de5 c74f48d027f4 cloudron/mail:2.7.0 "/addons/mail/start.…" 2 days ago Up 2 days 0.0.0.0:4190->4190/tcp, 0.0.0.0:25->2525/tcp, 0.0.0.0:587->2525/tcp, 0.0.0.0:993->9993/tcp mail 6331068cdae1 cloudron/mongodb:2.1.0 "/addons/mongodb/sta…" 9 days ago Up 2 days 3000/tcp, 27017-27018/tcp mongodb 9c77623d89c6 cloudron/postgresql:2.0.2 "/addons/postgresql/…" 9 days ago Up 2 days 3000/tcp, 5432/tcp postgresql da5ad557af5e cloudron/mysql:2.1.0 "/addons/mysql/start…" 9 days ago Up 2 days 3000/tcp, 3306/tcp mysql f822b1b3397f cloudron/sftp:0.1.0 "/addons/sftp/start.…" 9 days ago Up 2 days 0.0.0.0:222->22/tcp sftp 6c5788c3924a cloudron/graphite:2.2.0 "/app/code/start.sh" 9 days ago Up 2 days 127.0.0.1:2003-2004->2003-2004/tcp, 127.0.0.1:8417->8000/tcp graphite The db containers are appropriately named mysql, postgresql and so on. these containers are "shared" by apps. The app containers can be quickly identified using the image name like cloudron/org.wordpress.cloudronapp. If you have many apps of the same type (say 10 wordpress), then you can use the container labels to figure it out. You can run docker ps -f label=fqdn=blog.domain.com. The best way to access "mysql" (or any other db) is not via the mysql container. Instead, exec into the app's container and then use environment variables to access the mysql db. In the web terminal, there is a "mysql" button on the top bar, just click it and it will paste the command required to access mysql. Press enter to get the mysql console. finally, if web terminal is not very friendly for you, you can also use the CLI tool. After installing it, you can just cloudron exec --app blog.domain.com to get the same shell as the web one. Note, the CLI tool is installed on your PC/laptop and not on Cloudron!

@Trankery early next week is the plan. We also have a bunch of small regressions in Cloudron 5 that we are fixing as part of the release. It will all be in 5.0.4

@girish Okay. Would be nice to see in the future! E.g. "Ignore PTR".