"Being able to move the app's data location" is a reccuring need, we should really think about having a command to simplify and make the operation robust

[alexAubin]

cf various discussions, usually regarding Nextcloud, on how to move the data dir elsewhere. There are too many "tutorials" with at least 3 different methods involving dozens of CLI commands and supposedly only one of them really does work properly (the bind mount, but i'm not 100% sure either). People usually apply a naive symlink solution and later on this create hellish situation that we have to untangle.

cf YunoHost-Apps/nextcloud_ynh#670 (review) and YunoHost-Apps/nextcloud_ynh#674 and other similar threads in the issue tab and forum

The "proper"(?) bind mount solution seems documented in https://yunohost.org/en/administer/tutorials/external_storage

Ideally we should have a simple guided process by calling for example yunohost app move_data_dir $app /some/new/destination that:

• check that the destination doesn't exists yet (but the parent folder does) or at least is empty
• asks confirmation / warns that this may take a while
• mv or cp(?) or rsync the data (ideally gotta think about what happens if thing gets killed in the middle for some reason)
• applies the mount bind + adds it in /etc/fstab (but then we need to think about how we make sure that we ain't breaking /etc/fstab, which would be an epic disaster. For example what if people want to "undo" this whole operation, or already manually tweaked /etc/fstab, or moving an already-moved data dir to a new desination... Maybe using systemd bind mounts can be a better solution)

There are other ways to design this, such as moving the entire /home/yunohost.app rather than a single app data dir ... Or being able to move "system" stuff like /var/mail or maybe even /var/log idk

[kay0u]

applies the mount bind + adds it in /etc/fstab (but then we need to think about how we make sure that we ain't breaking /etc/fstab, which would be an epic disaster. For example what if people want to "undo" this whole operation, or already manually tweaked /etc/fstab, or moving an already-moved data dir to a new desination... Maybe using systemd bind mounts can be a better solution)

We could imagine building the fstab with a regen-conf. We don't touch it if it's manually modified and warn the admin via the diagnosis.
Systems bind mount sounds great too, and we can add a required field in the app's systemd service to wait for the mount before actually starting it. For example (https://unix.stackexchange.com/a/247547)

[zamentur]

I think i am the person who defined the mount bind in this tutorial as the proper solution...

I practice it on several servers:

• one of my server has been for example delivered with a bad initial partition schema, (/ with 8GB and /home with 500GB...), and i discovered it too late /o.
• others have a quick disk (ssd) for the system and slow disk (hdd) for storage

However, sometimes those mount bind method is not correctly supported during upgrade script, typically if you mount bind a dir like /var/www/APP/upload... or maybe /var/www/APP. An upgrade script could remove the install_dir and recreate it (without the mount bind) or failed cause it can't remove the dir...

So, moving specific app data or specific install_dir, should be tested carefully.

I guess the 2 others solutions are:

• symlink, but several security issues are related to symlink inside web directory
• edit configuration paths, but it's not generic, a lot of applications doesn't provide a way to change it (and if the app does, sometimes it's buggy)

So i guess mount bind is the better options, but we should take care how we manage it, an integration in yunohost core, could help to improve the current situation.

[kay0u]

However, sometimes those mount bind method is not correctly supported during upgrade script, typically if you mount bind a dir like /var/www/APP/upload... or maybe /var/www/APP. An upgrade script could remove the install_dir and recreate it (without the mount bind) or failed cause it can't remove the dir...

The very first step is to patch ynh_secure_remove to not remove a mount bind