rockybulwinkle
Dabbler
- Joined
- Aug 2, 2021
- Messages
- 25
When I was on TrueNAS Core 12, I had gotten cross-filesystem mounts working with NFSv4.
What this means is, I could have my "ROOT" dataset, and a number of datasets underneath it, accessible by adding a single path in the TrueNAS NFS shares. For example, here are some of my datasets:
Under TrueNAS 12, I was able to export a single ZFS dataset (data0/ROOT) and have access to all datasets underneath it through NFS. The client automounts the different ZFS datasets in both 12 and 13. Below I show what happens under 13, including the I/O error.
For reference, here is my /etc/exports under TrueNAS 13:
And in case it matters, my systemd unit file for mounting NFS on my client:
The funny thing is, if I create a new dataset under data0/ROOT through the command line, it is accessible through NFS as I expect, up until a reboot. After reboot, the dataset gives the same I/O error as before. So it's definitely still possible to get the old behavior.
As a workaround, I can add the ZFS datasets as additional paths to share in NFS, but I really need to get the old behavior working--at my work, we also use TrueNAS Core and keep many tens of paths and it would be cumbersome to add each one individually when we eventually upgrade to 13.
What this means is, I could have my "ROOT" dataset, and a number of datasets underneath it, accessible by adding a single path in the TrueNAS NFS shares. For example, here are some of my datasets:
Code:
data0/ROOT data0/ROOT/games data0/ROOT/movies
Under TrueNAS 12, I was able to export a single ZFS dataset (data0/ROOT) and have access to all datasets underneath it through NFS. The client automounts the different ZFS datasets in both 12 and 13. Below I show what happens under 13, including the I/O error.
Code:
[root@saturn data0]# mount | grep data0 192.168.2.229:/mnt/data0/ROOT on /data0 type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,nconnect=16,timeo=600,retrans=2 ,sec=sys,clientaddr=192.168.2.198,local_lock=none,addr=192.168.2.229) [root@saturn data0]# ls /data0/games ls: reading directory '/data0/games': Input/output error [root@saturn data0]# mount | grep data0 192.168.2.229:/mnt/data0/ROOT on /data0 type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,nconnect=16,timeo=600,retrans=2 ,sec=sys,clientaddr=192.168.2.198,local_lock=none,addr=192.168.2.229) 192.168.2.229:/mnt/data0/ROOT/games on /data0/games type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,nconnect=16,timeo=6 00,retrans=2,sec=sys,clientaddr=192.168.2.198,local_lock=none,addr=192.168.2.229)
For reference, here is my /etc/exports under TrueNAS 13:
Code:
V4: / -sec=sys /mnt/data0/ROOT -alldirs -maproot="root":"wheel"
And in case it matters, my systemd unit file for mounting NFS on my client:
Code:
[Unit] Description=Mount Share at boot After=network-online.target [Mount] What=192.168.2.229:/mnt/data0/ROOT Where=/data0 Options=nconnect=16 Type=nfs4 TimeoutSec=10 [Install] WantedBy=multi-user.target
The funny thing is, if I create a new dataset under data0/ROOT through the command line, it is accessible through NFS as I expect, up until a reboot. After reboot, the dataset gives the same I/O error as before. So it's definitely still possible to get the old behavior.
As a workaround, I can add the ZFS datasets as additional paths to share in NFS, but I really need to get the old behavior working--at my work, we also use TrueNAS Core and keep many tens of paths and it would be cumbersome to add each one individually when we eventually upgrade to 13.