Solved NFSv3/NFSv4, mounting, permissions, NFSv4 man-page, and more

[mefizto]

Hi

I don't think so.

I do not know if that means that you agree with me or disagree. Probably disagree based on the following text:

The V4: line does not export any filesystems. You still need an additional line in the exports file, even with V4:, and you can set permissions as you see fit on this exports line. Also, the exports(5) page states:

I understand that it does not export anything. But, the V4 line

. . . sets a single file system tree structure, rooted at
the point in the local file system tree . . .

So, for the single-pool case, it would be no problem. However, if one has several pools, there would be several tree structures. Unless, of course, I am again missing a concept.

Kindest regards,

M

 

[Jose]

I do not know if that means that you agree with me or disagree. Probably disagree based on the following text:

Disagree

I understand that it does not export anything. But, the V4 line
. . . sets a single file system tree structure, rooted at
the point in the local file system tree . . .

So, for the single-pool case, it would be no problem. However, if one has several pools, there would be several tree structures. Unless, of course, I am again missing a concept.

That does seem to be the case, unless symlinks are followed. You could then have a /nfsroot path with a bunch of symlinks off to the various ZFS filesystems. I do wonder how this would interact with ZFS's sharenfs, though.

 

[Jose]

I did a little experimentation this afternoon, and have found that T-Daemon is absolutely correct. Not only is the -network option useless in V4: lines, so is the -sec option. I tried the following exports file

V4: /zfspool -network 172.16.0.0 -mask 255.255.0.0 -sec=krb5
/zfspool/temp   -maproot=root

And I was able to mount, read, and, write with NFSv3 (mount server:/zfspool/temp /mnt) and NFSv4 (mount -o nfsv4 server:/temp /mnt) with absolutely no authentication whatsoever. That's a serious gotcha in the exports(5) man page.

Things that didn't work include mount server:/temp /mnt. The nfsv4 option is absolutely mandatory. I also failed miserably trying to get Kerberos auth to work with NFSv4. I know Kerberos is working because I'm able to ssh(1) to the NFS server using a Kerberos ticket. I suspect the gssd(8) daemon on the NFS client is not reading the /etc/krb5.keytab file for some reason.

One thing I found that may be of interest to mefizto is this message by SirDice:

ZFS NFS share options

I am trying to use the zfs set sharenfs command in order to share a directory with specific options, but whenever I try to add more than the -ro flag (ie zfs set sharenfs="-ro" library/Movies), the share stops being listed when I run showmount -e. I tried adding just the async flag as well with...

forums.FreeBSD.org

It looks like ZFS's sharenfs functionality is not so wonderful on Freebsd.

 

[mefizto]

Hi Jose,

thank you for the further investigation.

One thing I found that may be of interest to [FONT=monospace]mefizto[/FONT] is this message by [FONT=monospace]SirDice[/FONT]:

That is very interesting because as you might have seen from my experience, I was able to make the zfs set sharenfs work - after I figured out correct syntax. I could turn the sharing on/off, limit the share to authorized hosts, etc.

Apparently, the syntax and the options are different for different OSs and different implementation of the ZFS, as the gentleman in the thread found out. As I read it, he also did not run service mountd restart after each modification of the /etc/exports, as pointed out by our expert T-Daemon. Note that this does not appear to be necessary for using the zfs set sharenfs.

I cannot wait to try if I can use the zfs set sharenfs for different pools/datasets.

Kindest regards,

M

 

[T-Daemon]

What does the exported directory line look like?

The V4: line is the only line in /etc/exports. The export is realized by "sharenfs" property on pool/dataset:
zfs set sharenfs=192.168.0.115 storage/data

Which is translated in /etc/zfs/exports as

/storage/data     192.168.0.115

I'm just wondering why so many of the examples in that man page specify a network on the V4: line.

Apparently the one who added

                                            ... For the NFSv4 tree root, the
     only options that can be specified in this section are ones related to
     security: -sec, -tls, -tlscert and -tlscertuser.

to the exports(5) manual didn't bother to correct those V4: lines in the examples.

 

[T-Daemon]

Let us assume, for the sake of an argument that the nfsv4(4) is incorrect, i.e., it is not an implementation problem, and only one line in /etc/export is allowed. That would mean serious limitation. E.g., one's scheme to mount /storage/data/DIR_01 limited to authorized users only, but /storage/music worldwide would not be possible.

Unless creating for each NFS export a separate ZFS file system (dataset) with different "sharenfs" options instead of file system directories:

# zfs create sharenfs=x.x.x.111 storage/data/DIR_01
# zfs create sharenfs=on storage/music

/etc/exports

V4: /storage

 

[T-Daemon]

However, the /etc/export is not the only way to set the export, cf. https://klarasystems.com/articles/nfs-shares-with-zfs/ mentioned above. Could this aproach be used?

That's very interesting. I do wonder how ZFS's sharenfs interacts with NFSv4.

The same like a export line in /etc/exports.

 

[T-Daemon]

But, the V4 line

. . . sets a single file system tree structure, rooted at
the point in the local file system tree . . .

So, for the single-pool case, it would be no problem. However, if one has several pools, there would be several tree structures. Unless, of course, I am again missing a concept.

It's possible to unite all pools/datasets destined for NFS export under a single directory which serves as the V4: <rootdir> ( /storage in the following example) using the "mountpoint" property:

# zfs create -o sharenfs=x.x.x.111 -o mountpoint=/storage/pool2/data2    pool2/data2
# zfs create -o sharenfs=on -o mountpoint=/storage/pool2/music2    pool2/music2

zfs list -o name,mountpoint
NAME                 MOUNTPOINT
storage              /storage
storage/data         /storage/data
storage/date/DIR_01  /storage/data/DIR_01
storage/music        /storage/music
pool2/data2          /storage/pool2/data2
pool2/music2         /storage/pool2/music2

That does seem to be the case, unless symlinks are followed. You could then have a /nfsroot path with a bunch of symlinks off to the various ZFS filesystems. I do wonder how this would interact with ZFS's sharenfs, though.

Symlinks are not followed in NFS shares.

 

[mefizto]

Hi T-Daemon,

Thank you for your continued interest.

Unless creating for each NFS export a separate ZFS file system (dataset) with different "sharenfs" options instead of file system directories:

# zfs create sharenfs=x.x.x.111 storage/data/DIR_01
# zfs create sharenfs=on storage/music

Yes, that is the idea behind reorganization of the server; that is, to created dataset for each of the likely to be shared filesystem.

It's possible to unite all pools/datasets destined for NFS export under a single directory which serves as the V4: <rootdir> ( /storage in the following example) using the "mountpoint" property:

That is rather clever. thank you.

Hi Jose,

I do wonder how this would interact with ZFS's sharenfs, though

If I understand correctly, it depends on the implementation. Apparently, in some OSs, e.g., Solaris and its derivatives, the sharenfs command interfaces directly with the kernel, in others, e.g., FreeBSD, at least before OpenZFS, the sharenfs command creates an entry in /etc/zfs/exports as noted by T-Daemon.

I was unable to find out why the entry is not made in /etc/exports, my (un)educated guess is that by some additional trickery, the /etc/zfs/exports does not require to restart the mountd(8) daemon, not to be confused with T-Daemon.

Kindest regards,

M