Cloudron Forum

Ahh, I see. Its always the simple things. Thank you,

Noted with thanks @jdaviescoates

@Dont-Worry the apps run as containers and each container has it's own file system (completely different from the host filesysted). It is a sort of sandboxing for security. What this setup means is that, even if your disc is attached to the machine, the app containers won't see it! It will be available on the host ubuntu itself but not to the apps. Cloudron Volumes is a mechanism to expose these discs on host to the apps. Hope that clarifies! But if I could use it as a classic disc, I should mount it as a Cloudron volume If I understood correctly. Right, and there is no way around not creating a volume.

For anyone coming later, Ubuntu server use's netplan for configuration via files in /etc/netplan and you should not configure networking directly via systemd-networkd .network files. More details here. In my case if I ran sudo cat /etc/netplan/00-installer-config.yaml I got the following: # This is the network config written by 'subiquity' network: ethernets: enp2s0: dhcp4: true optional: true version: 2 The specific issue was that I had optional: true which I had done when I first setup this system as I originally had it setup to use wireless while doing the initial configuration and then switched to hard wired once I deployed it. Changing optional: true to optional: false, then removing the .network file I had put in /etc/systemd/network, and then rebooting I can now see that cat /run/systemd/network/10-netplan-enp2s0.network no longer has RequiredForOnline=no. Apparently the default is to require the network adapter to be in a routable state so now with the correct netplan configuration I get the right generated systemd-networkd configuration which properly waits for the interface to be routable before trying to mount volumes and all volumes mount as expected without intervention. The root cause behind this issue was me making a configuration change I meant to be temporary but then forgot to reverse and then because I didn't understand netplan my troubleshooting was in the wrong places.

@Supaiku not all apps have SFTP access though, just the ones for which it makes sense. Usually, apps where one needs to edit the code or upload files.

@girish Yes, all sorted, thank you for asking. Thanks to @robi's suggestion all we needed to do was the following: in terminal window for our WordPress app, at /app/code/wp-content/uploads we created a symlink (ln -s /media/ovitest ovitest) and then updated its permissions, just in case (chown -R www-data:www-data ovitest) then we could access the mp4 at https://<our_web_domain>/wp-content/uploads/ovitest/Red-cloud.mp4 Thank you very much all; we did enjoy finding the fix in the end. And of course we will make good use of it as we can now keep 10-20 GB of data, or even more, outside the WordPress data container, so out of the backup, but still reference this content on our website, which is great.

@crazybrad said in Unmounting volume leaves the "backup volume": Listmonk: Docker Error: Unable to pull image cloudron/app.listmonk.cloudronapp:202411131609490000. Please check the network or if the image needs authentication. statusCode: 500 This is the ipv6 rate limit issue which many are hitting. dockerhub seems to pushed some bad implementation of rate limits and it's wholesale cutting off network providers from accessing dockerhub. We have a workaround in place now for the new release.

@BrutalBirdie said in Volumes error on access but work? kinda?: Getting the picture? Yes! Excellent

@Stardenver Depends on how you use the volume. If you use the volume to store the app's data using data directory , then it's part of backup If you set it up as a mount of the app, then it's not.

@thebighead please update to 7.4.1 and try . Settings -> Check For Updates and update.

@nebulon How can I change it, I tried it and restart the server but it didn’t work. Can I install a older cloudron version ? 7.3.9?

@girish Your question got me wondering what was going on. Turns out, two apps on the volume both had caches that were insane (one due to an old uninstalled WP cache plugin that was removed, but maintained its 12 MILLION cached files, and the other was Mastodon, which needed some manual cleaning for the 800k files it had cached). Turns out there were just SO MANY folders/files that any attempt to backup or read the size would just time out. D'oh!

@privsec you can play with rclone mounts for this, however you want to minimize the network distance to avoid hiccups.

Ah, I guess the error message could be more descriptive. Currently there is a hard-coded allowlist of paths on the filessystem to be used as volumes, to avoid accidents where someone might add system folders. The list is at https://git.cloudron.io/cloudron/box/-/blob/master/src/volumes.js#L57

@zion I am not sure I fully understand your process there, but generally a disk partition is just a section of a hard drive. That section then has to be formatted with a filesystem, in this case ext4. This can be done via mkfs.ext4 /dev/<you partition identifier>. Once that is done, you should be able to just use the Cloudron dashboard UI to add it then. This makes Cloudron create the mountpoint for you.

@nebulon Thank you. After checking, it turned out that the issue is about efs not mounted. It seems to be messed up with security groups and/or network interfaces (eni). Hence closing this threat for now. Need to dig deeper and probably understand the concepts of security groups and eni better in AWS. Thanks for your help! Edit: Just realizing that can't set it to 'solved'

Hmm I still have permission denied inside the container to read /media/MyMount EDIT This time, it's working, for future reference, only thing I did was to set the home directory properly in the systemD service for each mount, remount them and then systemctl restart box or from the UI restart the box, my mounts are now visible inside the containers and I can read from them [image: 1734902378511-386b79d8-79cb-47db-8687-019194acef53-image.png]

Maybe there was some bug in our migration path. Will keep an eye out for related bug reports.

@msbt We won't break it intentionally atleast.

@SamGreenwood please give us more context via screenshots of what you're looking at. In general cloudron won't allow you to map volumes if they're not there, or move storage to the wrong mount points.