Cloudron Forum

On Cloudron, the only way to share directories is using Volumes . Is it possible to reorg your setup to use Volumes ? You might also have to use https://docs.cloudron.io/apps/#data-directory

My issue is resolved, adding a --allow-other parameter to the mount solved it, thanks @girish and @joseph

Think of each as a SaaS, I think the "correct" approach is to upload files in one app. That app exposes an API. Other apps then consume the photos API to do whatever . The whole sharing files approach is a relic of times when files were hosted on the same server and no sandboxing. But modern deployment/orchestration tech uses sandboxing, containers, docker compose, multiple servers . In such situations, sharing files assuming it's all code runs in same file system doesn't work well. app permissions/owner issues aside, most apps also have a database to track files and store extra metadata . If you remove and delete files from the filesystem without the app's knowledge, it all breaks. apps have to be written with all this in mind and most apps aren't written this way . lychee/nextcloud etc all have their own db and cannot share fs with others.

Usually, the issue here is that the SFTP service is not running . Services -> SFTP -> Restart maybe?

@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.

I suppose it can be marked as solved, but I still run into questions and small issues.

@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.