I understand your problem very well. Choosing the right drive (size, speed, security) for each service (or container) should always be within the administrator’s control. Traditionally, Linux offers reliable and transparent methods for this (via path mounts) that work seamlessly with nearly any application. Conversely, every Linux application should not only support these methods but must never sabotage them.
This freedom is essentially available with Neth8 as well—not only with the /home
directory but also deeper within the container structure. And it works reliably at first—until Neth8 takes the liberty, during restores, migrations, or upgrades, to independently define or rename container paths (incremental numbering). At this point, you can forget your mounts, and thus the service as well. For me, this is a major issue.
I’m glad the developers have now recognized the problem (choosing the right drive for the purpose) and I’m eagerly waiting for this feature. However, I disagree with their basic approach to solving it. From what I’ve been told about this concept, Neth8 would still decide where my data ends up. Moreover, drive assignment would apply to the entire container, and within the container, I still wouldn’t have the freedom to decide—just because of this ridiculous, arbitrary numbering system.
But I personally don’t want the entire Samba container on a single drive. I want to determine this for each share individually. Similarly, I’d like to assign individual mailboxes (e.g., the mail archive) to specific drives. This concept doesn’t support that, so it doesn’t help me.
Now, the developers aren’t responsible for my specific requirements; that’s entirely my responsibility. And I can handle it myself—if only Neth8’s relentless numbering system didn’t interfere.
There are plenty of straightforward ways to fix this.
I understand why the naming convention is as it is and that /home
is the simplest approach (due to user permissions). Even if that’s necessary, it should still be possible to find a suitable solution.
The best option would be to ask the admin before creating containers (creating, duplicating, restoring, migrating, importing) where they should be stored (within /home
or elsewhere) and then permanently respect that decision—no exceptions.
Possible Solutions:
1a. Before creating a container, ask which parent directory should be used (e.g., /home
, /mnt/ssd1
, /mnt/hdd2
).
Neth8 would still determine the container name itself (using the existing scheme to check for prior existence). The target drive (path) would be pre-defined or mounted by the admin, and the reliability of the mount could be verified upon restart before creating, restoring, or moving the container.
1b. Before creating a container, ask for the desired container name (within the naming convention, e.g., samba100
).
If the directory or its contents already exist, offer to empty it and adjust permissions (unless it’s an active container).
1c. At the very least, display the future path (including container name) before creating the container and wait for admin input (if necessary, pause to allow a persistent mount). The admin could then create the correct mount, and Neth8 would adjust permissions.
2. Pin the container path immutably for Neth8 in all variants.
This would allow for deeper custom mounts. Such pinning should only be enabled by the admin.
For My Needs:
For my purposes, it would be almost sufficient if:
- Before creating any container, the future name is displayed (and interaction is awaited).
- Instead of checking for the existence of the target folder (container name), offer to adjust permissions (or clear the folder) instead of unnecessarily and arbitrarily incrementing the numbering.
This seems so obvious to me (and the latter should be relatively easy to implement) that I hardly dare suggest it to the developers again.
Implementing a polished process for the “typical” Neth8 user—including automatic mount creation and a nice GUI—is, of course, more complex and time-consuming. But let’s wait and see—maybe someone will take pity and implement the simple solutions alongside it?