Date: Fri, 12 Jun 2026 07:24:34 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 296019] NFS4ERR_INVAL when Mac client creates file on ZFS share Message-ID: <bug-296019-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296019 Bug ID: 296019 Summary: NFS4ERR_INVAL when Mac client creates file on ZFS share Product: Base System Version: 15.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: freebsd.geography231@slmails.com Created attachment 271722 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=271722&action=edit tshark capture of error occurring I've got a FreeBSD server running 15.0-RELEASE-p10, exporting a ZFS shares via NFSv4 to a Linux client, no issues. I recently tried to connect a macOS 26.5 "Tahoe" client to it via NFSv4, and after figuring out the right configuration I needed to put into the Mac's /etc/nfs.conf, I was able to get it mounted. Reading and writing existing files from the Mac works as expected, but I cannot create new files. From the Mac's terminal: $ touch /Volumes/storage/test touch: /Volumes/storage/test: Invalid argument $ Doesn't matter how I try to do it, or with what app: if something tries to write to a new file on the NFS mount, it fails. Editing existing files works fine, though! I did a bunch of troubleshooting and eventually started trying to inspect the NFS conversation with a packet capture. I don't have the necessary understanding of the NFS protocol itself, so I enlisted an AI model to help me make understand it. After several rounds of investigation, and switching from tcpdump to tshark at the AI's request for its supposedly-greater NFS-decoding abilities, the AI arrived at the following conclusion: "Packet captures reveal that the client is sending time_create (birthtime) and explicitly setting flags to 0 in the createattrs. The FreeBSD NFS server translates these into a struct vattr and passes them to VOP_CREATE(). However, ZFS's implementation of VOP_CREATE returns EINVAL if va_flags is explicitly set to 0 (which ZFS interprets as a command to override internal default flags with zero, rather than a request to use defaults). The NFS server propagates this EINVAL directly back to the client as NFS4ERR_INVAL, causing the entire OPEN compound to fail." Now, my trust in AI is limited, but it did give me a patch for the kernel which resolved the issue for me: --- sys/fs/nfsserver/nfs_nfsdport.c.orig 2026-06-10 13:28:58.116498000 -0400 +++ sys/fs/nfsserver/nfs_nfsdport.c 2026-06-12 02:48:03.969107000 -0400 @@ -1991,6 +1991,9 @@ } if (!nd->nd_repstat) { if (ndp->ni_vp == NULL) { + if (nvap->na_vattr.va_flags == 0) + nvap->na_vattr.va_flags = (u_long)VNOVAL; + nd->nd_repstat = VOP_CREATE(ndp->ni_dvp, &ndp->ni_vp, &ndp->ni_cnd, &nvap->na_vattr); /* For a pNFS server, create the data file on a DS. */ That gave me some faith it might actually be right, so I figured I'd bring it to you experts and see whether or not I'm on to something here. Either way, I appreciate your time! I've attached the packet capture that shows the NFS conversation resulting in NFS4ERR_INVAL. To get the Mac to use NFSv4 and navigate nfsuserd successfully, I set its /etc/nfs.conf to: nfs.client.mount.options = vers=4 nfs.client.default_nfs4domain = localdomain And the relevant rc.conf entries on the FreeBSD system are: nfsv4_server_enable="YES" nfs_reserved_port_only="NO" nfs_server_flags="-u -t -h 192.168.4.6" nfsuserd_flags="-domain localdomain" rpcbind_flags="-h 192.168.4.6 -h 127.0.0.1" mountd_flags="-r -S -h 192.168.4.6" (The -h options were based on advice I found to avoid them binding to the alias IP addresses used by jails on the same system.) -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-296019-227>