Created a test share called “home”, now I cannot resize nor delete it. Receive error:
Operation not permitted on this share (home) because it is a special system share.
Detailed step by step instructions to reproduce the problem
Go to menu Storage > Shares > Create Share
Name: home
Pool: pool-1TB (used by other shares too)
Size: 256G
Click Submit
I did not use the “home” share or map it to any “File Sharing” NFS/Samba/SFTP. Nor did I enable any Replication. Here are the details for all my shares. Initially there was no “home” share before I took this screenshot:
@andyz welcome to the Rockstor community. I assume you’re running one of the latest versions of Rockstor (one of the 5.x versions)?
I am surprised that you were able to create a test share called “home” in the first place. Usually, during installation a home directory is created and a subsequent directory associated with the administrator account on the Rockstor OS disk (“ROOT”).
What is your disk setup? You have a separate OS disk vs. a pool of disks that you have created, correct (something like the below)?
Hi Dan
Yes, I’m running 5.0.10. This is a fairly new install. There were no initial pools or shares after the install completed. I didn’t delete or remove anything. I’ve created one pool (pool1-1TB) and a few shares. First was share1, then rockon, vault-data, vault-cert and sftp-share. Lastly I created home and then found I couldn’t edit it nor delete it when trying to back it out. I too assumed that if “home” is some special system name that the software would have not let me attempt to use it, but I typed it in, Hit Submit and it created as below.
Here are all the layouts of disk, pool and shares. I don’t have any Replication tasks setup and there are only some snapshots of the rock-on share, but that’s it.
I think that might be the reason why the home share did not show up to begin with. So, it implies that during some reinstallation that step was not completed (or a disk unplugged in between some reboots), possibly.
I think using the CLI you kind of have to follow the process that the UI follows (but by doing it in the command line no limitation on removing the “home” drive will exist). But, I think getting a viewpoint from @phillxnet would be good, too.
Dan,
Appreciate you pointing out the orange import arrow. I wasn’t aware of that, nor that I had to potentially click that at any time during the install. There were no disk changes, nor reinstalls, this was all from a first time install from scratch first right after creating the VM.
Here’s what my mount points look like at this point in time
/home and /mnt2/home are both there and truly separate partitions/spaces.
I feel like I shouldn’t click the Import arrow on my ROOT at this point in time. Hopefully @phillxnet may be able to share the CLI steps I could attempt to remove /mnt2/home by hand.
As from the rework of our low-level disk interpreter code in:
We purposefully no longer auto import the system pool. Named ‘ROOT’ as this was always a bad idea generally. And the tooltip on that system import (preserved for flexibility and continuity if needed) advises not to do this unless you are an advanced user.
It seems thought that we (read I) missed adding a block on the creation of a subvol named “home” which exists on the ROOT pool. And we have a requirement that all shares (btrfs subvols) are uniquiely named on a system wide basis.
So we simply have a bug post the above changes on providing no ‘fence’ to avoid folks creating a ‘home’ Share, as this then blocks their ability to import the system pool. And what we see is our old fences in place that block folks from doing some things with a share called ‘home’ as it is, as indicated, special. Except in this case it’s just a name clash that we allowed to happen.
Yes, btrfs sees these as two seperate spaces: but unfortunately we still have this limitation re unique names per system for all btrfs vols/subvols. I’ll create an issue to get the fence in place to avoid folks running into this. It was previously not possible as a “home” share always exited already. But out newer simplified and I think more intuitive/informative start-with-no-pools stance has allowed for this to happen.
Your out here is, as @Hooverdan suggests, to remove your data pool btrfs subvol named “home” via the CLI assuming you have no data in there already. You can then assess if you really need to import the system Pool to get access to the real-and-special home but this is strongly discouraged (hence the new tooltip info). Far better to keep a strict seperation between data and system: hence the new stance re no default import of the system pool.
Agreed.
Will do, if not beaten to it time wise. But only after recreating your coner-case bug so I can report in the issue the same. We then have a proof of work-around in case others end up in the same situation.
Hope that helps, and I’ll update here once that issue has been created.
I’ll reproduce locally and report on a safe work-around for those caught between current testing and post fix release for this missing ‘fence’. Again if someone doesn’t beat me to it.
@andyz do first be sure you have no data in this subvolume first as all data under the associated btrfs subvolume (Rockstor Share) will be lost when the subvolume is removed via CLI action.
Cheers for this report by the way: much appreciated. And very timely as we do need this fixed before the next stable release. As a result I’ve now added that issue to our next Stable milestone:
@andyz OK, so just testing our proposed fix for this corner bug:
Re:
Once you have ensured there is no data of value in the non-ROOT pool home Share (btrfs subvol), I appreciate you have already indicated this; but for others in similar but not identical situations:
As the root user, given you already have a Rockstor managed mount point at /mnt2/home:
un-mounts the ‘live’ home subvol mount: N.B. this could equally be as a result of our ROOT pool import; but is non destructive.
References the inadvertent duplicate home subvol via it’s parent Pool mount to reduce ambiguity.
A Web-UI refresh, via browser, should then no longer show this Share (btrfs subvolume) that as @Hooverdan indicated should not have been allowed by the Web-UI in the first place: in development testing channel allowed this from new installs post our not auto-importing the ROOT pool. As there-after our existing block on system-wide duplicate share names would have come into play.
Hope that helps. I’ll report here again on when the pre-release fix has been merged and released: likely as part of 5.0.14-0 rpm hopefully. Still making sure it does what was intended.
