Cloudron Forum

Maybe https://forum.cloudron.io/topic/1579/var-lib-docker-overlay2-getting-full?_=1760112116784 is helpful: @nebulon said in /var/lib/docker/overlay2 getting full: For a start, docker images are often quite large, composed of a multitude of filesystem layers on top of each other. To mitigate the problem a bit, all Cloudron apps share the same base image, that helps a bit. The appsdata folder really only contains the data from within the apps, so that heavily depends on your own usage. The application code, so to speak, is inside those docker images.

@nebulon said in Disk usage update problem: Ah thanks for the clarification. Maybe we can think of some different UI which has an overview and some drilled down info if wanted. This would be awesome

Did anything change @hakunamatata Also, Cloudron 9 might resolve this.

Thanks for reporting. This was bug in the container. I have reduced the verbosity to 0 in the mongod configuration for the next release. For the moment, you can simple delete or truncate the log files.

I can't quite make out why it's crashing . @lukasgabriel if possible, can you write to support@cloudron.io and I can debug this further ?

@girish Thanks

Yeah, I guessed the same after reading the debianforum wiki Results after running it a couple of times: sudo hdparm -t /dev/sdb1 /dev/sdb1: Timing buffered disk reads: 192 MB in 3.00 seconds = 63.92 MB/sec Timing buffered disk reads: 200 MB in 3.00 seconds = 66.58 MB/sec Timing buffered disk reads: 224 MB in 3.01 seconds = 74.44 MB/sec Timing buffered disk reads: 236 MB in 3.01 seconds = 78.31 MB/sec Timing buffered disk reads: 248 MB in 3.01 seconds = 82.33 MB/sec Timing buffered disk reads: 234 MB in 3.01 seconds = 77.69 MB/sec

@Recliner2042 ah fair, that's a bug then. Can you contact us at support@cloudron.io , so we can debug this further?

@shifty thanks for the update! Glad it got solved.

Might not be limited to „lock“ files: Today I had a similar error (first time ever!) du error: Command failed: du -Dsb "/home/yellowtent/boxdata/mail" du: cannot access '/home/yellowtent/boxdata/mail/vmail/[REDACTED]/mail/dovecot.list.index.log.2': No such file or directory

@girish

Solved! Just for the sake of someone else stumbling into the same issue : Backup SSHFS mount with hetzner storage box should always be mounted pointing to the exact sub folder where backup will be stored, so the path would be /home/yourfolder and the URL to the server should not contain any path. Now, if you use the same storage volume mounted a second time, as a volume to be added to specific apps then the URL is always ID.your-storagebox.de and the path field is simply / no need to specify any folder. The issue here is that I had it to mount the URL of the storage box ID.your-storagebox.de/home + / in the path and that was the origin of the mess, the odd part is that it did mount and the volume was usable via the filemanager just fine, it's just that the hdparam.sh script would freak out due to this confusion in the path. Anyway, solved !