Cloudron Forum

@girish said in Bug: When adding of a volume fails, docker container creation fails, removal of old volume impossible: nvm, I reproduced it. If you change the path behind Cloudron's back, it doesn't work. I think it's correct to error since that path doesn't exist anymore. But anyway quick fix is: simple create empty /media/SG2TB/M/Calibre on the server and then Retry configure will work. After it comes up, remove the mount from the app, delete the volume, add new volume with correct path, add mount into app... That's what I did, I went behind Cloudron's back ... and didn't think of the obvious solution presented by you! Thank you.

@scooke You might want to try the AppConfig>Storage section in the Cloudron App UI to add mounts or move the entire app to a new volume.

@nebulon Not so clear. The volume disconnected again. The "Remount Volume" button did not help but "Edit Volume" and saving (unchanged settings) worked.

Restic: https://restic.net Supported repos out of the box: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html Other repos when combining restic with rclone: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#other-services-via-rclone A starting point: https://docs.cloudron.io/guides/community/restic-rclone/

Hi @nebulon, thank you for the information. I already checked one of the apps was using the volume. After deleting the volume from the app. I can delete the old storage volume. Thank you once again.

We have a media group that the app's user is part of. See https://docs.cloudron.io/volumes/#sharing

@murgero Thanks, yeah, definitely not doing that now Just looking for the simplest solutions with what we already have. Since the functionality is already there, this is more of an workflow interface feature to just make it available at an earlier stage in the process, and to avoid the additional step and decisions later to do the exact same.

Sounds good! It was also odd that some other apps were affected by the restart-looping Nextcloud instances.

If you relocate an app (changing app data directory) all data will be copied over. See https://docs.cloudron.io/apps/#data-directory Please note that not all filesystems are suiteable for this. The docs link has some info on that.

Hi guys, A quick update for anyone who may run into this in the future. Yes, that did the trick, I was able to create a /mnt/sync/ directory under Volume, and executed "Retry Task." One thing that I did notice was that I couldn't restore from the last version of the backup, but the one previous to that went through just fine. Really glad for such such a smooth migration process!

To add to what @necrevistonnezr said, add the hard drive as a Cloudron volume and use https://docs.cloudron.io/apps/#data-directory to move the app's data into that volume.

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