@girish editing the unit files to add Before=docker.service did not work for me. I can't see any of my files. However, if I try to mount these shares in the host system by editing fstab file, they are available on boot.

I can also confirm @msbt 's observations. If after boot, I go to the Volumes UI and delete, re-add shares, all these files become available. I then have to go the app (Jellyfin, Navidrome, etc.) and reboot the app to see the shares..

@nebulon Yeah I went so far to migrate to a fresh ubuntu installation to find out if there is something wrong on a system level but that didn't help either. Moving to an external drive did work though for some reason. But that's not what I want since that is a much more expensive solution…

@brutalbirdie Yup, all sorted and working as intended for now.
I have upvoted your comment above. Thank you.

The full stack trace is:

16/07/2021 17:58:24 :: [console] Error writing to collectd.localhost.df-sdc1.df_complex-used: Unable to read header (/var/lib/graphite/whisper/collectd/localhost/df-sdc1/df_complex-used.wsp) 16/07/2021 17:58:24 :: [console] Unhandled Error Traceback (most recent call last): File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 266, in <lambda> inContext.theWork = lambda: context.call(ctx, func, *args, **kw) File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 122, in callWithContext return self.currentContext().callWithContext(ctx, func, *args, **kw) File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 85, in callWithContext return func(*args,**kw) File "/usr/lib/python3/dist-packages/carbon/writer.py", line 189, in writeForever writeCachedDataPoints() --- <exception caught here> --- File "/usr/lib/python3/dist-packages/carbon/writer.py", line 165, in writeCachedDataPoints state.database.write(metric, datapoints) File "/usr/lib/python3/dist-packages/carbon/database.py", line 124, in write whisper.update_many(path, datapoints) File "/usr/lib/python3/dist-packages/whisper.py", line 740, in update_many return file_update_many(fh, points, now) File "/usr/lib/python3/dist-packages/whisper.py", line 747, in file_update_many header = __readHeader(fh) File "/usr/lib/python3/dist-packages/whisper.py", line 294, in __readHeader raise CorruptWhisperFile("Unable to read header", fh.name) whisper.CorruptWhisperFile: Unable to read header (/var/lib/graphite/whisper/collectd/localhost/df-sdc1/df_complex-free.wsp)

The last line gives a hint that the graphite file is corrupt. So, I removed all the whisper files in /home/yellowtent/platformdata/graphite/whisper/collectd/localhost/df-sdc1 and graphs seems to work after that.

@atridad Maybe a good idea to check the health of the hard disk ? Also, since we hit the systemd issue on the same server.

@girish HAH nevermind. Its me being a Linux noob...

turns out I mounted the drive itself not the partition. The files are there.

@jdaviescoates said in Volume disk space strangeness:

/me goes to reduce the size of the volume back to a perfectly sufficient 10 GB...

Oh, bollocks. You can't decrease the size of Hetzner Cloud Volumes, only increase them. So I'd have to create a whole new one and then and then and then...can't be bothered with all that so I guess I'll just stomach the slightly increased cost of 15 GB over 10 GB.

@odie Still stuck on this. The culprit is definitely that the usb network card fails to receive its configuration on boot. I cannot get netmanager to configure and initialize it at all. Only the two manual commands seem to work:

sudo ip addr add 192.168.9.101/24 dev enxc4411eb4c476 sudo ip link set dev enxc4411eb4c476 up

I have tried various thing with network manager, and I've tried adding a config file to systemd-networkd under /etc/systemd/network/ - the only thing I achieved, was to have every network freeze when I inserted the usb ethernet adapter (only to unfreeze as soon as I disconnected it). Tried keeping it disconnected for longer, just to see, but connections were frozen until I unplugged the usb network card. So I had to remove these config files.

Can anyone offer suggestions? I don't know where to even look for assistance on this now... Thanks!

@drpaneas Ah thanks, I think I found the bug. It seems a "permission denied" issue is being flagged incorrectly as directory does not exist. The chown you did essentially changed permissions and fixed the issue.

@annaooo To add to this, it's best to create shared folders under /srv, /mnt, /opt instead of /home/yellowtent. The /home/yellowtent is the home directory of the user which cloudron platform runs as and it's not meant for user data. In fact, it won't let you create a volume under /home/yellowtent.

@girish said in See volume disk space usage on System Info:

This is fixed in 6.1 - https://git.cloudron.io/cloudron/box/-/issues/756

I see one of my volumes (an ext4 Hetzner Cloud Volume), but not the other (CIFS Hetzner Storage Box).

Is there any way to display disk usage of CIFS mounts too?

Thanks!

@mario said in it is possible to share data between apps ?:

Through volumes, sure.

yes, I just found it, this is why it was familiar to me because it was mentioned in the Cloudron 6 release note 😉

@nebulon for me it is no issue anymore because of the Volumes. In this Minio app I don't share the Volume with other apps and it's not backed up just like I want.

Hopefully in future releases, like @girish wrote, when they will be backed up there will also be an option to never backup specific Volumes?

@girish it works like a charm, absolutely awsome!

@jdaviescoates Yes, looks like there is some fd leak and they are nearing a fix.

It looks like restarting docker and running configure again did the trick. Fixed!

@girish Thank you for your world-class customer support! Sending blessing! ☘️⭐️💎

Never used Git, will keep that in mind for reporting any issues that I might come across with Cloudron apps!

Now that I know that shared volumes is what I'm after 😜 (I thought it might be different somehow if it was a specific permission for an app to read data outside of it's docker container), how can I set up and use a shared volume if it's not exposed on the interface? Or is this something that's not trivial and best left alone till it's stably implemented?