@Kuro Welcome to the Rockstor community forum.
Not a full answer but I can, for now, jump in on this part of your query:
This is, in part, a legacy of our older v3 and of our underlying OS (linux). We left it in place to help those migrating from our prior v3 arrangement. But there are two major problem with using /home as-is:
- It is a btrfs subvolume (share in Rockstor speak) on the system drive.
- User areas, auto created by our underlying OS (linux) are not subvolumes but simple directories.
In the case of 1. you will not benefit from the separation of system and data that is highly advisable. I.e. the system (read operating system) lives on the Pool (btrfs volume) labelled “ROOT” where there is no data redundancy via raid level etc. And so if used for data at all it should be for more throw-away data such as say the Rock-ons root, or othewise replaceable non critical data. The system (OS) is important of course but it can be replaced easily by a re-install. But user data is almost always not this way.
A more regular Linux server install would normally put the entire /home mount point on a raid array. But in our case we generally advise against the use of the /home partition but have left it as visible in the Web-UI for compatibility reasons with our older v3 which did this. But we did remove the far more problematic and confusing “root” subvolume.
In the case of 2. As these auto created directories (user home directories) within the /home subvolume on the “ROOT” labelled system Pool (btrfs volume) are only directories; our Web-UI is unable to distinguish them. I.e. one cannot manage these individually within the Web-UI of Rockstor as it works only on the btrfs volume (Pool in Rockstor speak) and the btrfs subvolume (Share in Rockstor speak) levels. Which can be confusing as subvolumes (Shares) appear in the directory structure as directories! But are more akin to embedded file systems. Hence our Web-UI working at this level, we get seperation of data into shares of a pool of collected disks, where each share is a sub-part of the entire Pool space resource.
So in short, I think you would be well advised, if you wish to stick as closely to the default Rockstor configuration as possible, to avoid entirely the use of the the /home partition. Unless you have, on-staff, advanced linux admins who may also have to dabble in a little Python/Django to contribute to our project to enable any modification you find to be necessary. But I at least hope, in the future, for us to deprecate the surfacing of the /home subvolume on the system pool, at least by default, in time. But we have had not public discussion about this so I’d much rather not spring this on folks, some of which may be relying on a use of this default subvolume in a way we haven’t anticipated.
Yes, most likely (ignoring my above notes on this) and I will leave the exact likely custom samba config for this to others here on the forum who are more familiar with this than myself. But again, this /home, artifact is just that a legacy element of our OS surfaced via it’s subvolume nature. We support subvolume use on the system drive and so we show all created ones plus the “home” for reasons outlined above.
This does bring up a possible future enhancement however where we offer a /home Pool and the subsequent user areas (directories) are actually subvolumes in their own right. However we currently have way too much of a backlog to approach level of enhancement: but I like the idea, especially given Sambas awareness (under certain configurations) of this setup. But that is for another day.
I would suggest that you find a naming convention that works for your users and that is compatible with what we have now on the user creation and share creation front. But note the following:
“john.appleseed” for example, is a perfectly valid share (subvolume) name. But not a Rockstor user (linux OS username) we support. But you could choose to have “-” in username and create a share with the “.” such as your users expect. As I have done in the above example. And the resulting share appears as expected in a client file-manager app:
Then create shares on either a dedicated “home” Pool or as shares within your existing data pool so that they can, individually, be assigned, rights wise, and export wise, to the relevant users. Which is all seeming rather long winded actually, but workable with a lower number of users.
N.B. our base OS (openSUSE Leap) defaults to users belonging to the “users” group. This facilitates sharing of shares/exports across users if you are not careful with the share permissions themselves.
I.e. you can set for example on the share:
So the default group of users has no access.
And we see the effect on the mount point used by Rockstor to access this share (btrfs subvol):
ls -la /mnt2/
…
drwx------ 1 john-appleseed users 42 Oct 24 12:32 john.appleseed
Note also that as this is a subvolume of the “test-pool-balance” Pool it will also appear as a directory within the parent pool:
ls -la /mnt2/test-pool-balance
total 16
drwxr-xr-x 1 root root 86 Jul 11 19:08 .
drwxr-xr-x 1 root root 290 Oct 24 11:56 …
drwx------ 1 john-appleseed users 42 Oct 24 12:32 john.appleseed
drwxr-xr-x 1 root root 42 Sep 29 19:02 tailscale-config
But we access it internally via it’s dedicated mount point (setup by Rockstor) under:
/mnt2/share-label-here
to keep things simpler within the code. We also, as you see, mount each Pool (btrfs subvol) at it’s ‘top’ level and by it’s label to enable us to pool level things. E.g. the “/mnt2/test-pool-balance” listing above.
Hopefully others can chip in with more info on these topics.
So in short, avoid using the /home subvol as it’s on the system pool, not the data pool which is where all your valuable data should be, where you can have redundancy options via multi-drive pools and redundant storage via the raid options of these non system pool. Plus if the system is separate from the data, one can far more easily rebuild such systems in the even of major failures. Or import the data pool/pools on a replacement/upgraded system if that time comes.
Hope that helps.
