@girish This makes a ton of sense, although I'm not quite sure if I'm doing it right. Under what you linked to, the section should be under the Resources tab, although I think it's moved to the Storage tab (no problems with that, I just wanted to make sure I'm handling it correctly).
The part that's a little confusing is how 'App Data' and Volumes tie together in storage (now it seems this may be resolved as you said, since your working on Volume updating at some point in the future).
Anyways, App Data says to mount an external EXT4 disk, which I assume is done with the 'Mounts' interface right below it. However, the mount says that you are mounting 'Volumes'.
The documentation says 'App Data' is backed up. However, the documentation also says that 'Volumes' are not backed up. So that does leave me a little perplexed as to whether the data will be backed up or not. I think according to your comment, that it will be backed up (because you did say it would no matter where it is on the server). But I just thought I'd check 🙂
In any case, thanks for your help, and hope you have an awesome rest of your week.
@fbartels The thing is I can't check since the volume now works for me. But what I'm saying is that the issue was wider than just not being to write with the NC app, since data in the volume was not read / written into correctly anywhere (in NC app, in NC terminal and in Cloudron file browser) and that has nothing to do with the www-data user as far as I can tell.
And by the way you are right that the user in the terminal is root so it's true that being able to write with the terminal could still mean there is a restriction on the folder which would prevent the NC app to write. But as explained above, I don't believe this was the problem in my case.
@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…
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
File "/usr/lib/python3/dist-packages/carbon/writer.py", line 189, in writeForever
--- <exception caught here> ---
File "/usr/lib/python3/dist-packages/carbon/writer.py", line 165, in writeCachedDataPoints
File "/usr/lib/python3/dist-packages/carbon/database.py", line 124, in write
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.
/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.
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?