Solved NFSv4 export cannot read-write on Linux client

Hello,
I have a ZFS filesystem exported as NFSv4 from FreeBSD 14. The Linux client mounts the file system but cannot write. I can see the files and traverse the file system, and the permissions look right as viewed from Linux.
Any help is highly appreciated!
Thanks
]On FreeBSD 14.1 Stable
Code:
louis@grendel:~ $ uname -a
FreeBSD grendel.local 14.1-STABLE FreeBSD 14.1-STABLE stable/14-n268493-78c66b88cc91 GENERIC amd64

Code:
louis@grendel:~ $ cat /etc/exports
V4: /home
/home -rw -alldirs -maproot=nobody -network 192.168.1.0 -mask 255.255.255.0
/home/louis -rw -alldirs -maproot=nobody -network 192.168.1.0 -mask 255.255.255.0
/home/jvl -rw -alldirs -maproot=nobody -network 192.168.1.0 -mask 255.255.255.0

Relevant sections of /etc/rc.conf
Code:
louis@grendel:~ $ cat /etc/rc.conf
hostname="grendel.local"
ifconfig_bxe3="inet 192.168.1.10 netmask 255.255.255.0"
defaultrouter="192.168.1.1"
zfs_enable="YES"

# NFS server
rpcbind_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
mountd_enable="YES"

The ZFS file system is exported:
Code:
louis@grendel:~ $ zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
storage           1.11T  5.29T    24K  /storage
storage/home      1.10T  5.29T  1.10T  /home
storage/home/jvl   514K  5.29T    25K  /home/jvl
storage/media      602M  5.29T   601M  /storage/media
storage/www        639K  5.29T    31K  /usr/local/www

louis@grendel:~ $ zfs get sharenfs storage/home
NAME          PROPERTY  VALUE     SOURCE
storage/home  sharenfs  on        local
On Linux Mint 22.1
Code:
louis@louis-ThinkPad-A485:~$ inxi -S
System:
  Host: louis-ThinkPad-A485.local Kernel: 6.8.0-59-generic arch: x86_64
    bits: 64
  Desktop: Cinnamon v: 6.4.8 Distro: Linux Mint 22.1 Xia

The file system is mounted on /mnt/nfs
Code:
louis@louis-ThinkPad-A485:~$ cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p2 during installation
UUID=688db7dc-8328-420e-9d56-659510cd6295 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=A688-15FB  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
grendel:/ /mnt/nfs nfs4 defaults 0 0

As shown by mount, showing only relevant lines:
Code:
louis@louis-ThinkPad-A485:~$ mount
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
grendel:/ on /mnt/nfs type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.13,local_lock=none,addr=192.168.1.10)

cd to the mount point and looking at the files, where the ownership and permissions look reasonable.
Code:
louis@louis-ThinkPad-A485:/mnt/nfs/louis/share$ ls -l
total 94558
drwxr-xr-x  3 louis louis        4 Jan  7 16:17  a485backup
-rw-r--r--  1 louis louis       72 May 11 05:16  blah.txt
drwxr-xr-x  3 louis louis        3 Jan 17 16:03  CanonEOS
-rwxr--r--  1 louis louis   611716 Mar  2 21:25  contacts.vcf
drwxr-xr-x  3 louis louis        5 May 10 11:25  Documents
-rw-r--r--  1 louis louis      101 Sep  3  2024  id_ed25519_louis_grendel_local.pub
drwxr-xr-x  6 louis louis        8 May  6 22:37  Movies
drwxr-xr-x 22 louis louis       22 Apr 27 01:44  Music
drwxr-xr-x  3 louis louis        3 Feb 17 08:53  Pictures
drwxr-xr-x  2 louis louis       43 May 11 04:14  SMSBackupRestore
drwxr-xr-x  3 louis louis        6 Apr 24 06:50  t480backup
-rw-r--r--  1 louis louis 43685260 May  3 10:18  t495_hmm_en.pdf
-rw-r--r--  1 louis louis 41744013 Apr 30 22:23  tp_a485_hmm_en.pdf

I can view a file, but cannot write it:
Code:
louis@louis-ThinkPad-A485:/mnt/nfs/louis/share$ cat blah.txt
This is a test file.
It has two lines in it. 
Oops no, there are three.
louis@louis-ThinkPad-A485:/mnt/nfs/louis/share$ touch blah.txt 
touch: cannot touch 'blah.txt': Permission denied
 
Hi there.

14.1-STABLE stable/14
Probably you noticed it as well, this stable is End-of-life.

Rich (BB code):
louis@grendel:~ $ cat /etc/exports
/home -rw -alldirs -maproot=nobody -network 192.168.1.0 -mask 255.255.255.0
...
-rw is not a valid exports(5) option on FreeBSD. Read/write permission is granted by default. Denying write permission requires a setting. Check system messages for mountd(8) errors:
grep mountd /var/log/messages

Rich (BB code):
louis@grendel:~ $ zfs get sharenfs storage/home
NAME          PROPERTY  VALUE     SOURCE
storage/home  sharenfs  on        local
If there is a /etc/exports file with defined mount points for NFS remote mounts, then there is no need for a ZFS dataset "sharenfs" property setting. Choose one or the other but not both. If "sharenfs" is used and set properly, remove all but V4: line from the exports file.

I can view a file, but cannot write it:
To permit user "louis" on the remote Linux Mint client write permission for the /home/louis/share directory on the FreeBSD NFS server , the group id of the "share" directory must match the id of the Linux Mint user "louis", and have group permission read/write/search(x) bits set.

LinuxMint, example
Code:
# id -g louis
1012

FreeBSD NFS server
Code:
# pwd
/home/louis

# chown :1012 share/

# chmod 775 share/


EDIT

Rich (BB code):
louis@grendel:~ $ cat /etc/exports
/home   ...
/home/louis   ...
/home/jvl  ...
Rich (BB code):
louis@grendel:~ $ zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
storage           1.11T  5.29T    24K  /storage
storage/home      1.10T  5.29T  1.10T  /home
storage/home/jvl   514K  5.29T    25K  /home/jvl
storage/media      602M  5.29T   601M  /storage/media
storage/www        639K  5.29T    31K  /usr/local/w
/home and /home/louis looks like the same file system.

The exports line should be
Code:
/home  /home/louis  -maproot=nobody  -network 192.168.1.0  -mask 255.255.255.0
 
Hi,
Thanks for the hints. No, I had not noticed the end-of-support. Thank you for your diplomacy.

I cleaned up /etc/exports to remove the extra lines, keeping only the V4: /home line and setting the sharenfs ZFS property.

It turns out that it has to do with UID/GID issues, but I thought that NFSv4 sent names over the wire rather than numbers, using nfsuserd. Setting the share directory to the same numeric user and group ID as on Linux works fine.

I'm calling it solved, however I wonder why nfsuserd isn't mapping the permissions correctly. Is this a case of setting up Kerberos to negotiate permissions? Or is that inviting more trouble? I'm also using Samba for the Win and Mac clients.

Best
--Louis
 
Back
Top