@jwoods To address your following question:
If you take a look at the following forum post where the various Rockstor services were discussed, in a related but different context, you will see the rough structure of the services:
But to accomplish what Rockstor does, or tries to do in some circumstances :), is actually more complicated than might first be thought. So it turns out that volume/mountpoint mappings is mostly what Rockstor does in the background, in the context of user programmed preferences via Web-UI input stored in a database (Django/Postgresql). So this question is hard to answer briefly; but in short it’s instantiated via our codes interpretation of the database of prior entered preferences or defaults.
Essentially first rockstor-pre.service runs /opt/rockstor/bin/initrock which in turn runs /opt/rockstor/src/rockstor/scripts/initrock.py
(basic sanity checks and db migration if required)
rockstor.service runs “/opt/rockstor/bin/supervisord -c /opt/rockstor/etc/supervisord.conf”
further environment (more sub services) setup.
Followed finally by rockstor-bootstrap which kicks off the mount stuff essentially by running: /opt/rockstor/bin/bootstrap which setups up the env to run /opt/rockstor/src/rockstor/scripts/bootstrap.py which in turn mainly does some basic btrfs prep, some rockstor network setup (which uses nmcli under the hood) and to your request finally does an API call on commands/bootstrap, hence the services name.
So we finally get to what kicks off the mounts etc in the API here:
which continues one for a bit to try and account for all supported capabilities.
This is to ‘top’ or bottom level of rockstor depending on how you look at it.
And to your specific issue, rockstor failing to setup NFS mounts after reboot with your vol/subvol/exports setup, we have a little further down the in that same file the following:
Having now hopefully answered that question, at least initially I have attempted to reproduce your issue with the following setup via Rockstor’s Web-UI (non advanced mode, ie just via form entry) and have the following directly after setting 3 NFS exports up:
cat /etc/exports
/export/data 192.168.1.159(rw,async,insecure)
/export/ovirt 192.168.1.159(rw,async,insecure)
/export/isos 192.168.1.159(ro,async,insecure)
with the consequent mounts setup ‘live’ via Rockstor as expected via the given command:
mount | grep 'data\|ovirt\|isos'
/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered)
/dev/sdb on /mnt2/data type btrfs (rw,relatime,space_cache,subvolid=310,subvol=/data)
/dev/sdb on /mnt2/isos type btrfs (rw,relatime,space_cache,subvolid=309,subvol=/isos)
/dev/sdb on /mnt2/ovirt type btrfs (rw,relatime,space_cache,subvolid=311,subvol=/ovirt)
/dev/sdb on /export/data type btrfs (rw,relatime,space_cache,subvolid=310,subvol=/data)
/dev/sdb on /export/ovirt type btrfs (rw,relatime,space_cache,subvolid=311,subvol=/ovirt)
/dev/sdb on /export/isos type btrfs (rw,relatime,space_cache,subvolid=309,subvol=/isos)
These command outcomes were unaffected post a subsequent reboot.
However on trying ‘harder’ to reproduce you issue I think I have identified a bug re our mounts of NFS. I am as yet unsure if this could lead to your exact issue but theirs definitely something not quite right here. But I strongly suspect it is related. Try also using my above command re the grep of mount. I’m hoping this may give us more info on what’s going wrong here.
Could you also look to your systems journalctl and the contents of the main rockstor.log:
less /opt/rockstor/var/log/rockstor.log
Directly after a reboot where you had previously established NFS exports.
From the latter above code snippet a failure in the NFS part of bootstrap their should have left an “Exception while bootstrapping NFS: …” log entry which may be of some use in pinning down why your NFS bootstrap fails and mine here does not (yet at least).
Yes, as these subvols are rockstor managed/mounted and not fstab managed they don’t appear in /etc/fstab. Fstab is the origin of a request not the reflection of a mount existing. So stuff in fstab is enacted at boot time by systemd these days but as we manage the mounting the rockstor code does, or tries to do, these mounts such that it can apply the Web-UI stuff etc without live editing /etc/fstab which is left to manage the base system critical mounts only.
Once we manage to pin down the exact reason for your observed failure, I can create an issue with it’s definition. This should in time lead to a fix. But we first have to identify the exact reason and get a simple reproducer so we an define the issue appropriately.
Apologies for the slow response but NFS is not something I’ve looked at for a while, both in itself and Rockstor’s implementation of it.