Solved NFS client mapping root as nobody

I

ImanolBarba

Hi everyone!

I'm trying to build a shared environment between VMs, I currently have a Debian box running a NFSv4 server and FreeBSD 10.2 as client.

It seems that the FreeBSD NFS maps the local root user as nobody, even when the server allows mapping root correctly (no_root_squash) and mounting from a remote Ubuntu box results in root user correctly mapped.

Is the Debian box at fault, or should I change some configuration I missed in the BSD client?

My current rc.conf is:

Code: 
hostname="www"
[...]
# NFS
nfs_client_enable="YES"
nfsuserd_enable="YES"
nfsuserd_flags="-domain local.lan"
 
Are the domains correct on both sides? Try this rc.conf.
Code: 
nfsuserd_flags="-verbose -domain local.lan"

/var/log/messages should have more clues on what username mappings are happening behind the scenes. There's probably an equivalent idmapd(8) option for the Linux side that will give the equivalent information.
 
I added the -verbose flag but no messages appeared in /var/log/messages, I also increased verbosity to 3 on Linux rpc.idmapd but no errors showed up.

Fun experiment: I tried creating another user (let's call him testuser) in both client and server and both the UID and username get mapped correctly (lets me create files, no permission issues, owner is consistent, etc.).

So, my bet is that for some reason FreeBSD nfsuserd refuses to map root as root on the remote system (maybe for security reasons?).

Or maybe because the GID 0 in FreeBSD is called wheel and in Linux its called root there’s a conflict?
 
Do you have any -maproot options listed in your exports(5) file on the server? That's what controls how UID 0 is mapped to the clients.

Oh, wait, you're using FreeBSD on the client, not the server. Nevermind.
 
I cloned my VM and changed the wheel group to root (in name) and no dice.

So I guess it's the client that's preventing me in some way to map the user as root

Maybe it expects the remote server to behave in some special way, like FreeBSD servers do with the -maproot option (as phoenix pointed out)

Any ideas welcome :)
 
Last edited by a moderator:
I did a workaround by creating a user in both systems with the required permissions.

It's not pretty, but using NFS as root isn't much prettier either.

I'd like to know if anyone has any suggestion though, as mounting NFS and accessing as root has its benefits (remote root fs in diskless environments among others)

Thanks for the help though :)
 
NFSv4 needs UID's to match between the server and the client, unless you are using Kerberos. Quoting from the nfsv4(4)


Code: 
Although uid/gid numbers are no longer used in the NFSv4 protocol, they
will still be in the RPC authentication fields when using AUTH_SYS
(sec=sys), which is the default. As such, in this case both the
user/group name and number spaces must be consistent between the client
and server.

However, if you run NFSv4 with RPCSEC_GSS (sec=krb5, krb5i, krb5p), only
names and KerberosV tickets will go on the wire.
 
You need to map the uid/gid on both servers if you want the same user to have access.

I was not referring to the root user...
 
gkontos said:
You need to map the uid/gid on both servers if you want the same user to have access.

I was not referring to the root user...
Click to expand...
Yes, sysctl vfs.nfsd.enable_stringtouid was added for a reason since some implementations will fall back to sending the UID/GID over the wire. It may work depending on the particular mix of clients/servers.

But back to the matter at hand, the -verbose flag for logging should tell you something. Here's the logs from a FreeBSD client taking to a FreeBSD NFS server.

Code: 
Oct  7 00:11:07 <daemon.err> router nfsuserd:[3285]: Added uid=0 name=root
Oct  7 00:11:07 <console.info> router kernel: Oct  7 00:11:07 router nfsuserd:[3285]: Added uid=0 name=root
Oct  7 00:11:26 <daemon.err> router nfsuserd:[3285]: Added gid=0 name=wheel
Oct  7 00:11:26 <console.info> router kernel: Oct  7 00:11:26 router nfsuserd:[3285]: Added gid=0 name=wheel

If you are seeing a different mapping than that should be investigated.
 
Argh nevermind guys, I just found out today it was my fault: I missconfigured the Linux server and it didn't map root correctly...

Sorry for the trouble and thanks a lot for your answers, I will now mark this thread as solved.
 
ImanolBarba said:
Argh nevermind guys, I just found out today it was my fault: I missconfigured the Linux server and it didn't map root correctly...

Sorry for the trouble and thanks a lot for your answers, I will now mark this thread as solved.
Click to expand...

Could you please share exactly what you did and solved the problem? Are the UID same or not?
 
You must log in or register to reply here.
Back
Top