@HansFranz Welcome to the Rockstor community:
For larger file systems having quotas enabled can be unworkable. First be sure of the version your are running via:
yum info rockstor
As the temp channel had a bug which caused available to be show as installed:
The reason to make certain is that only the Stable Channel can have quotas disabled and still function.
Once you have ensured you are actually running latest Stable you can disabled quotas via the Web-UI, the above forum link has a picture of where to do this.
Presumably this means you can see the suspect shares data when accessing it from it’s pool mount point, ie /mnt2/Data/share-name
But the dedicated mount for that share:
/mnt2/share-name
is empty.
In which case you may have a poorly pool and it has gone read only, which is what the following could be suggesting:
Or were you trying to re-create a share by the same name. That is not wise as the share would seem to be already prescent form you initial report of finding it’s date. Btrfs pools present their subvolumes date within subdirectories. But these subdirectories can be mounted as if they are whole filesystems in their own right. So the question is why is the original share not mounting. This could be down to pool issues.
So this looks like the the data is visible via the pool sub directory but it’s btrfs subvol is failing a mount.
Important:
Are you trying to add a share that has existed before? Are you trying to add the failed-to-mount share again (unwise).
I suspect your pool has gone read only, which is what they do when they discover a problem. This is to protect the existing data from corruption where possible.
So first off make sure the yum command states the real installed version as you understand it.
The folks on the forum may be able to take it from there.
The output of the following would also be useful initially to let folks know of the general arrangement:
btrfs fi show
And with such a large array you most likely are going to have to disable quotas, but not until you have confirmed the rockstor version number from the terminal. This situation is likely to imporove once we have completed our move to our pending Built on openSUSE version were we will inherrit many quota related fixes and speed-ups.
So do nothing until you have confirmed the version number as if really a Stable channel install then you can disable quotas from the command line and that might actually be the only problem as with an array this size and if you have many files / snapshots / lots of data (likely) the system could go so slowly as to block the mount of the various shares. And this happens on boot, and you stated flaky behaviour and non responsive Web-UI during boot.
So either poorly pool or so slow the mounts failed, but in any case you need to try disabling quotas while you find out more, but you can’t do that unless you have Stable release and if you are only reading from the Web-UI and we don’t know if this has ever been a stable (and you may not know either as you state having inherited it) then best check to be sure, then disable them if you can. But if pool is read only then you may well find out and will then have to take it from there.
Hope that helps.