Cloudron Forum

@jan_z
That's interesting.
I thought those xorg packages were installed by the cloud vendors for remote desktop sessions from their consoles.

@adrw A quick and crude solution I found was to change the permissions of the files and directories under /app/code/tmp/cache:

docker exec -it OPENPROJECT-CONTAINER_ID chown -R www-data:www-data /app/code/tmp/cache

docier ps to get the container ID of your OpenProject.

However, the issue here is that new root owned directories will be arbitrarily created from time to time depending on your usage, so that aforementioned command needs to be executed accordingly. I'm thinking to put it in a cron job and make it run every 5 minutes.

Please note that I've had only a few hours of testing of this, and I don't know how it can impact the system in the long run.

We definitely need a proper and permanent solution.

Reference here, but it doesn't really apply to our issues.

@marcusquinn True.

Now it made wonder how the big guys, i.e. Google, Amazon, etc., were able to get away with a similar incidence. I'm certain that their services were used for nefarious purposes at one time or another. I guess they're just too big to fail.

If I understand it correctly, they were saying that because of some malware content being hosted at one of their servers, their endpoints were blacklisted by major DNS service providers around the world.

Am I correct?

@nebulon,

So right after I restarted, the cache directory got emptied out and began creating 6 new directories which are all owned by www-data.

But after a few minutes, more directories appeared, and one of them was owned by root. Again, after a few more minutes, more directories were created and another root owned directory appeared. All these happened without any user interactions (e.g. Clicking a link or logging in to OpenProject).

I'm getting the same errors as @adrw as well.
This is on a fresh install of Ubuntu 20.04 and OpenProject.

This is the log:

Dec 24 15:22:40 E, [2020-12-24T08:46:40.026946 #259] ERROR -- : [current_user=Anonymous] Permission denied @ dir_s_mkdir - /app/code/tmp/cache/DD6/B70: Permission denied @ dir_s_mkdir - /app/code/tmp/cache/DD6/B70

And when I checked the permissions:

drwxr-xr-x 21 www-data www-data 4096 Dec 24 08:45 DD5/
drwxr-xr-x  3 root     root     4096 Dec 24 06:10 DD6/
drwxr-xr-x 21 www-data www-data 4096 Dec 24 08:48 DD7/

Is it the issue with the directory, DD6, being not writable by www-data?

Edit: There were 3 directories owned by root among 49 directories.

@girish,

Yay!!! It's working now.
But I think the logs are at /home/yellowtent/platfordata/logs/collectd/collectd.log.

Thank you!

@girish,

No dice. Rebooted and waited for like 3 hours.
I'll update if it changes later.

It's ok. I'll just wait for 6.0.
Thank you.

Oh. My mistake then.

I thought Ubuntu 20.04 is already supported, because I checked the script, cloudron-setup, and it no longer prohibits me from installing on Ubuntu Fossa (It used to though).

I didn't do a dist upgrade. It was installed on a clean Ubuntu 20.04.1.

So far, everything else seems to be OK (touch wood). But then I'm just testing Open Project.

I'm having a similar issue as well.
Edit: Please let me know if I need to open a new thread.
Edit2: Not a new system. It's been running for about a week.

Vultr, Ubuntu 20.04.1, Cloudron 5.6.3

System Info

Chrome - Console log

df -Th

Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  1.9G     0  1.9G   0% /dev
tmpfs          tmpfs     394M  1.7M  392M   1% /run
/dev/vda1      ext4       76G   15G   57G  21% /
tmpfs          tmpfs     2.0G     0  2.0G   0% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     2.0G     0  2.0G   0% /sys/fs/cgroup
tmpfs          tmpfs     394M   24K  394M   1% /run/user/125
overlay        overlay    76G   15G   57G  21% /var/lib/docker/overlay2/4aa0476d5e9f54a77fb245e7c391ce49bc6a80fc7120300cc8933261bd32878a/merged
overlay        overlay    76G   15G   57G  21% /var/lib/docker/overlay2/a6ea14043f42c07087d1f133d33d50e161cef9342b8360ed6601c3bdc292dfcb/merged
overlay        overlay    76G   15G   57G  21% /var/lib/docker/overlay2/1b24ff91fc4450d69d8419879fc46925d20327bfcafdb466e143752a7b5db1a1/merged
overlay        overlay    76G   15G   57G  21% /var/lib/docker/overlay2/60e4893426213b77982f2b47efca482389d720e7148ed9a4cb205348e8929ca6/merged
overlay        overlay    76G   15G   57G  21% /var/lib/docker/overlay2/69b4dd2921b7120b9d3b33089d9cbe945655bdddd61df8f5d06ece86c461350c/merged
overlay        overlay    76G   15G   57G  21% /var/lib/docker/overlay2/dea7c24f3096cb7737d60b10794ce8c2d3d4249f0c48707f54d6a3fa443508ee/merged
overlay        overlay    76G   15G   57G  21% /var/lib/docker/overlay2/c28552a10f0f0736d46f6be64046b05a5195fd16b9f844a9fd95316ecf3755e5/merged
overlay        overlay    76G   15G   57G  21% /var/lib/docker/overlay2/0d8cf0c75789aab0bfc2a2802995a65c06e7a0476ba4315ff73ece45d34e25e0/merged
tmpfs          tmpfs     394M     0  394M   0% /run/user/0

Cloudron system log

Dec 02 11:59:50 box:apphealthmonitor app health: 1 alive / 0 dead.
Dec 02 12:00:00 box:disks Checking disk space
Dec 02 12:00:00 box:janitor Cleaning up expired tokens
Dec 02 12:00:00 box:janitor Cleaned up 0 expired tokens.
Dec 02 12:00:00 box:tasks startTask - starting task 40. logs at /home/yellowtent/platformdata/logs/tasks/40.log
Dec 02 12:00:00 box:shell startTask spawn: /usr/bin/sudo -S -E /home/yellowtent/box/src/scripts/starttask.sh 40 /home/yellowtent/platformdata/logs/tasks/40.log 0 400
Dec 02 12:00:00 box:disks checkDiskSpace: disk space checked. ok: true
Dec 02 12:00:00 box:notifications alert: id=diskSpace title=Server is running out of disk space
Dec 02 12:00:00 box:apphealthmonitor app health: 1 alive / 0 dead.
Dec 02 12:00:00 box:shell startTask (stdout): Running as unit: box-task-40.service
Dec 02 12:00:01 box:shell startTask (stdout): Finished with result: success
Dec 02 12:00:01 box:shell startTask (stdout): Main processes terminated with: code=exited/status=0
Dec 02 12:00:01 box:shell startTask (stdout): Service runtime: 1.164s
Dec 02 12:00:01 box:shell startTask (stdout): Service box-task-40 finished with exit code 0
Dec 02 12:00:01 box:tasks startTask: 40 completed with code 0 and signal 0
Dec 02 12:00:01 box:tasks startTask: 40 done
Dec 02 12:00:10 box:apphealthmonitor app health: 1 alive / 0 dead.

@girish said in Reboot button missing in 5.0.3?:

Alright, we will add it back

Thank you so much.

@girish .. It's not exactly a must-have, but it'd be definitely nice to have it there.
Edit: Thanks for the prompt response.

I could no longer find the reboot button in the latest update (5.0.3). Anyone else?