Block creation of system reserved Share names

[phillxnet]

Thanks to forum member andyz for highlighting this issue. We have a hard limitation regarding unique btrfs vol (Pool) and btrfs subvol (Share) naming. But prior to (current testing phase):

Un special-case system drive btrfs-in-partition treatment #2824 #2835

we always auto imported the ROOT system Pool (btrfs vol), with it's 'special' home Share (btrfs subvol). And similarly identified this home Share by name as 'special': limiting the available functions as a result. But we are now missing a block against folks creating a home Share which would prior to the referenced changes always already exist. So our existing no-duplicate Share/Pool names block avoided the duplication.

Ergo we now need to guard against folks creating a home Share via the Web-UI as this would then cause a potential clash if, at a later date, folks wanted to import the system Pool. It would also introduce a source of confusion re two subvols named the same - which we normally avoid via our existing hard limitation.

---

Forum thread reference: https://forum.rockstor.com/t/newly-created-test-share-named-home-cannot-be-resized-nor-deleted/9620

[phillxnet]

N.B. similarly we should block all default subvol names found on our upstream OS ROOT pool. As we filtered most out from the Web-UI and surfaced only home by way of continuity form our prior OS base of CentOS which has a very different arrangment btrfs wise. But we aimed to make user transition as smooth as possible: hence this gradual transition to proper system/data separation re no default system pool import etc.

[Hooverdan96]

Do you think that will end up being a static filter, or is there a way to suss out the existing ones and add to a filter set? Not sure that these things change all that much in upstream, so a dynamic way might be overkill?

[phillxnet]

@Hooverdan96 Not sure really. There is also a complexity wrinkle re subvolumes as we default to boot to snapshot. I remember it being quite tricky to assess root subolumes in a boot to snapshot arrangement (our default) and we account for non boot-to-snapshot also. So I think, at this stage in testing, I was going to opt for the default filesystem arrangement as per openSUSE which I think is not likely to change that much. We can enhance some later: and we currently have a static filter for removing them form the Web-UI so I was hoping we can use the same to also block their creation also.

[phillxnet]

Having a quick look now - given we need to get Stable out as soon as possible.

This is our existing excludes for subvols not to display/concern ourselves with:

rockstor-core/src/rockstor/fs/btrfs.py

Lines 57 to 84 in 4d60a2c

	ROOT_SUBVOL_EXCLUDE = [
	"root",
	"@",
	"@/root",
	"tmp",
	"@/tmp",
	"var",
	"@/var",
	"boot/grub2/i386-pc",
	"@/boot/grub2/i386-pc",
	"boot/grub2/x86_64-efi",
	"@/boot/grub2/x86_64-efi",
	"boot/grub2/arm64-efi",
	"@/boot/grub2/arm64-efi",
	"srv",
	"@/srv",
	"usr/local",
	"@/usr/local",
	"opt",
	"@/opt",
	"root/var/lib/machines",
	"@/.snapshots",
	".snapshots",
	]
	# Note in the above we have a non symmetrical exclusions entry of '@/.snapshots
	# this is to help distinguish our .snapshots from snapper's rollback subvol.
	# System-wide subvolume exclude list.
	SUBVOL_EXCLUDE = [".beeshome", "@/.beeshome"]

I'm thinking, at least initially, that we exclude the creation of all SUBVOL_EXCLUDE (which should be Web-UI excludes) and have an additional list containing 'home', so we still show home on ROOT pool import but have it blocked via it's own blacklist.

That static list has thus-far served us for the entire life-cycle of Leap 15.0 (from beta). So it should serve us OK for the remainder of Leap at least: fingers crossed.

[phillxnet]

Closing as:
Fixed by #2882