mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

poptrek · 2024-01-30 17:31:55

I can't seem to figure this out. When I try to to mount i get a mount.nfs4: Operation not permitted error. I am using nsf4. I can't use nsf3 cause the server is a WSL guest(Port forwarding took 2 days to figure out just for 2049). The directory I am trying to share is a ZFS dataset. I have followed the instruction in the ZFS and NFS on the Arch wiki for setting up a NFS share. The debugging for NFS in the arch wiki is not helpful at all. The only consensus with what the trouble might be is mismatching UID/GID but once again the wiki and no one else seems to specify how to correct this.

I have tried setting the user names to the same on both boxes. I have tried chown the directory that is being mounted to on the client to user:user. I tried nobody: on the exported server directory. I am at complete lost on how to fix this. The server is a ubuntu box in WSL. The client is another NAS on bare metal running Arch with ZFS pools. ZFS is setup correctly on the Ubuntu server. Samba on the Ubuntu Server works and is connectable from the host(I can't export this to LAN without breaking things otherwise I would stick with samba unless I can export a network share, one could hope)

I can mount the root directory of the Ubuntu Server on the Arch Client but when I try to cd into the ZFS exported directories I get a operation not permitted error. Nothing popped up in dmesg in client or server. Nothing under systemctl status on server. When I run the mount command on the Arch Client Any help would be appreciated

Last edited by poptrek (2024-01-30 17:55:46)

seth · 2024-01-30 18:16:18

Can you mount the zfs shares from any other client?

https://wiki.archlinux.org/title/ZFS#NFS
https://wiki.archlinux.org/title/NFS#Custom_export_root
https://wiki.archlinux.org/title/NFS#St … the_server

poptrek · 2024-01-31 01:34:46

No it doesn't work on a another machine. So I have wire shark installed. It does seem to be permission issue. It is returning an access denied packet, then sending a NFS4ERR_PERM packet before destroying the session. So this is an ACL issue? So a matching group and gid must be present on both machines and in the ACL with RWX for this directory I am trying to share?

I created a new groups called NFS and set the id to 1050 on both server and client. I then set the ACL to add this new group with rwx permissions. I added both my admin user and root to this new group on the client. I restarted nfs-server on the server and still nothing

I have tried starting the nfs-idmapd.service with no luck. I set the nobody user to the main user on both machines and the nobody group to the nfs group I created on both machines int he idmap.conf files. Does any one have a good quality NFS instructions? The arch wiki for NFS is all over the map on what to do and isn't very clear for the non NFS verse user in mind

My only thought and how is how zfs generates the exports default options are

(sync,wdelay,hide,crossmnt,no_subtree_check,mountpoint,sec=sys,rw,secure,root_squash,no_all_squash)

My thinking the secure is not allowing port 2049 to connect which is stated in the NFS wiki. But who would design a system to block a connection on its default port so I have no hope in my theory

And my final note. Is this theory is true the secure option blocks the default port of nfsv4 ... Please NFS devs allow 2049 as part of the secure option ...

Also in the ZFS Arch wiki someone with rights may want to state the by default sharenfs=on default the secure option which breaks everything for nsfv4

Last edited by poptrek (2024-01-31 03:01:18)

seth · 2024-02-08 23:15:07

But who would design a system to block a connection on its default port so I have no hope in my theory

Sun Microsystems; the default port for NFSv3 is 111 and this is all irrelevant since the restriction applies to the client, not the server port.
Are you suggesting it works w/ NFSv3 (on port 111)?
Is the zfs-share.service running?

poptrek · 2024-02-09 04:45:57

So the problem is server side in that ZFS defaults to using the secure option or it just uses NFS defaults, not sure which. This breaks NFSv4. NFSv3 is fine, like you said it uses ports that aren't broken by the secure option but v4 uses port 2049 which is broken by the secure option and must be set to use insecure if using v4 if staying with the default port. It is stated in the wiki that anything above 1000 is not permitted to be used I just never made the leap that the default port for v4 was also blocked. It should be mentioned in the Arch wiki for NFSv4 the insecure option must be set when using v4 default port of 2049

seth · 2024-02-09 08:15:33

Again: the restriction applies to the clients, not the server.
And it applies to them regardless of NFSv3 and NFSv4 => what do you actually use on the client side to access the share?

If you're mounting it w/ mount.nfs you can control the source port, https://man.archlinux.org/man/nfs.5.en#resvport
The "insecure" option is only relevant for unprivileged accesses through eg. kio or gio (ie. if you try to mount the share w/ dolphins nfs:// protocol)

If you can access the share (only) after (only) replacing "secure" (which should be default anyway) w/ "insecure" that will more have to do with your client then your server
You can also try to change the nfs port on the server, https://man.archlinux.org/man/nfs.5.en#port=~2 & https://man.archlinux.org/man/nfsd.8.en#p (the former allows you to force using rpcbind)

poptrek · 2024-02-09 09:01:39

Per this section https://wiki.archlinux.org/title/NFS#Custom_export_root

The insecure option allows clients to connect from ports above 1023. (Presumably only the root user can use low-numbered ports, so blocking other ports by default creates a superficial barrier to access. In practice neither omitting nor including the insecure option provides any meaningful improvement or detriment to security.)

Yes it is client but the server is the one refusing the connection. I think this is the only mention that the server will refuse the connection if its above 1023 but no mention that insecure needs to be set or the default port needs to be changed for NFSv4 to work. My fault for not making the leap that a default setting would be blocked by another default setting. IMO that is poor coding and design choice

WorMzy · 2024-02-09 09:14:35

Mod note: moving to Networking

seth · 2024-02-09 09:23:01

IMO that is poor coding and design choice

You can invent a time-machine, travel back to 1984, tell Doc Brown to stay away from the Lybians and then let Sun know about your opinion.

Either way: this has nothing to do with NFSv4.
If your client (which you've still not mentioned) uses an unprivileged port, it'll be blocked from access. Regardless of NFS version or server port, as long as the "secure" option is in place.

Arch Linux

#1 2024-01-30 17:31:55

mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

#2 2024-01-30 18:16:18

Re: mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

#3 2024-01-31 01:34:46

Re: mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

#4 2024-02-08 23:15:07

Re: mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

#5 2024-02-09 04:45:57

Re: mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

#6 2024-02-09 08:15:33

Re: mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

#7 2024-02-09 09:01:39

Re: mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

#8 2024-02-09 09:14:35

Re: mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

#9 2024-02-09 09:23:01

Re: mount.nfs: Operation not permitted Ubuntu Server Arch Client ZFS share

Board footer