I’ll address some of your questions here, and I think we largely agree on the problem definition, even if we’re considering different solutions.
Yes, that’s likely the default Podman path for rootless container volumes. I recommend avoiding direct writes into these paths, as this can lead to file ownership issues.
That setup is fine, as long as you’re not using an unsupported filesystem like NFS. If you decide to mount /home on a separate disk, choose a local SSD, as recommended for the root filesystem.
Directories cannot be pre-created; the core creates them as needed during the node/add-module action. If an existing directory is found, this action may fail.
This approach may be difficult to manage and support. If you’re referring to mounting after module creation, the feasibility depends on the volume’s purpose and the filesystem used.
Yes, in the NS7 migration tool, the Sync button serves as a breakpoint. At this point, you could remove and re-create any app volume during migration, as pressing it triggers a full rsync of the volume contents. Whilst I’m not 100% that this method works in any situation, it is worth testing it.
Right, the previous link is not clear. This one should be more appropriate for rootless containers: NS8 Add storage path setting like in minio to other apps - #10 by davidep
In restore and move procedures, selecting the “right drive” is possible if it’s managed by the core, as mentioned above. Doing it manually sounds error-prone.
Keeping solution costs low is likely beneficial for all users. For example: large slow affordable disk for Samba shared folders, small fast expensive disk for the root filesystem.
Yes, I believe this aligns with our overall project goals. For advanced configurations, we can provide guidance for sysadmins to override the default behavior when necessary. But Sysadmin freedom is not a goal on its own. We must consider that both app developers and support teams are “system users” as well.