Unable to mount TrueNAS dataset on Ubuntu using NFS

[12pharoh21]

Hello all,

I have a new TrueNAS server that I have configured recently but I'm having some trouble with NFS shares. I have tried this on my other TrueNAS server and it does the same thing. I can mount the top level folder without a problem, but any child directories are not able to be mounted. My server config is as follows:

TrueNAS-12.0-U7
MB - ASUS SaberTooth X58
CPU - Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
RAM - 24GB
LSI MegaRAID SAS 9361-4i
LSI LSI00412 0.6 Meter Internal Cable SFF8643 to x4 SAS8482
-Disks - 4x8TB HGST SAS NAS drives in RAIDZ1

I have one pool spanning the whole drive array called Media, then a child dataset called Movies. I have setup the NFS share using /mnt/Media and running cat /etc/exports returns the following:

Code:

/mnt/Media -alldirs -quiet -network xxx.xxx.xxx.xxx/24

In my Ubuntu server I am trying to mount the Movies folder, but I get the following error

Code:

mount.nfs: timeout set for Tue Dec 21 17:26:46 2021
mount.nfs: trying text-based options 'vers=3,addr=xxx.xxx.xxx.xxx'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying xxx.xxx.xxx.xxx prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying xxx.xxx.xxx.xxx prog 100005 vers 3 prot UDP port 791
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting xxx.xxx.xxx.xxx:/mnt/Media/Movies

If I change the command to just mount /mnt/Media it will mount without an issue. Should the flag -alldirs not allow me to mount any of the child datasets? I have typically been using SMB shares in the past, but most everything I am using with this are Ubuntu servers, so I want to move to NFS shares instead. I tested this on my existing TrueNAS-12.0-U6 server and it did the same thing as this one. Is there a bug that won't allow you to mount child datasets?

 

[blanchet]

-alldirs does not work for child dataset, it works only for directories.
If you have child datasets, you have to define a NFS share for each children.

 

[12pharoh21]

-alldirs does not work for child dataset, it works only for directories.
If you have child datasets, you have to define a NFS share for each children.

Gotcha, that makes sense. Thank you for the clarification on that, it is appreciated.

 

[12pharoh21]

-alldirs does not work for child dataset, it works only for directories.
If you have child datasets, you have to define a NFS share for each children.

I had read somewhere that you shouldn't have SMB and NFS shares on the same dataset, is that accurate?

 

[Samuel Tai]

I had read somewhere that you shouldn't have SMB and NFS shares on the same dataset, is that accurate?

In general, yes, because locking isn't shared between the protocols, so different users can step on each other without being aware of doing so. However, I have a dataset I share out via NFS for my Plex container, and also via SMB so I can add media. As I'm the only one accessing this share, either via the Plex interface or via SMB, I'm careful not to do things in both interfaces at the same time.

If you have multiple users, you'll have problems.

 

[jgreco]

I had read somewhere that you shouldn't have SMB and NFS shares on the same dataset, is that accurate?

Well, it's an overgeneralization, perhaps. You should not attempt to have lock and write access to the same set of files using two different protocols, because you are not guaranteed to get cooperation between protocols that have made different architectural decisions. This is only actually a problem when you DO try to lock or write to files simultaneously with different protocols. Some people find that hard to wrap their heads around and they made a simpler rule. Some of us share out files using NFS, SMB, AFP, *and* have local UNIX access as well and don't have a problem with it, because we don't break that policy.

 

[12pharoh21]

In general, yes, because locking isn't shared between the protocols, so different users can step on each other without being aware of doing so. However, I have a dataset I share out via NFS for my Plex container, and also via SMB so I can add media. As I'm the only one accessing this share, either via the Plex interface or via SMB, I'm careful not to do things in both interfaces at the same time.

If you have multiple users, you'll have problems.

Well, it's an overgeneralization, perhaps. You should not attempt to have lock and write access to the same set of files using two different protocols, because you are not guaranteed to get cooperation between protocols that have made different architectural decisions. This is only actually a problem when you DO try to lock or write to files simultaneously with different protocols. Some people find that hard to wrap their heads around and they made a simpler rule. Some of us share out files using NFS, SMB, AFP, *and* have local UNIX access as well and don't have a problem with it, because we don't break that policy.

Thank you both for the explanations, that makes total sense. This TrueNAS is only going to be used for my Media storage for Plex (rapidly running out of space on my other TrueNAS server), so sharing out through SMB and NFS won't be an issue for me. Thank you both for your continued support. I appreciate it.

 

[jgreco]

Not a problem. And for the purposes of this discussion, "local UNIX access" (such as editing a file directly on the NAS with vi, etc.) should be considered a file access protocol. It tends to be compatible with NFS, due to the commonality of the underlying UNIX-style file locking being propagated correctly across NFS -- except when it isn't propagated correctly, which is why it's sanest to consider each of these things as a separate "problem domain" for writing/locking purposes.