unexpected NFSv4 permissions behaviour

davidovitch · 2012-05-22 22:09:50

I used to successfully mount my Arch desktop drives on my Ubuntu laptop, using NFS. Recently I switched my laptop (which is my production machine for work) to Arch as well. Since the desktop is configured as the NFS server, I assumed it was simply a matter of configuring the laptop as an NFS client. An overview of the config (as explained on https://wiki.archlinux.org/index.php/NFSv4 and http://www.brennan.id.au/19-Network_File_System.html):

Server

The /etc/exports config file:

/exports                some-ip-address(rw,sync,no_subtree_check,no_root_squash,fsid=0)
/exports/home      some-ip-address(rw,sync,no_subtree_check,nohide,all_squash,anonuid=99,anongid=99)

nobody:nobody is 99:99 is the same on both server and client. Further, the client and server share the same UID and GID in /home.

and bind the exports to the mounts in /etc/fstab

/home     /exports/home      none     bind    0    0

the /etc/idmap.conf is identical on the client and the server:

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = dtu.dk
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

On the client the /etc/fstab specifies the mounting options as follows:

some-ip:/     /mnt/server    nfs noauto,exec,rw,_netdev,sync   0  0

I can successfully mount the partitions on the client, I have read write access, but there is one thing I fail to figure out: if I check the permissions of the mounted share, I see (when doing a ls -lah on the client):

drwxr-xr-x 12 4294967294 4294967294 4,0K 10 apr 00:04 data1

Which indicates the file is owned by user -2:-2 (that's how Nautilus sees the UID:GID of the share). That is not what I expected: I was expecting to see the real owner of the mounted files. This is relevant especially when rsyncing my laptop (and I want to keep the file permissions) with the desktop configured as NFS server. I've been trying to fix this for weeks, but I fail to see what I am doing wrong. Changing the anonuid,anongid in the /etc/exports on the server to the actual owner has no effect. As if the id mapping deamon is not doing a proper job?

Am I missing the obvious here? Maybe the NFS configuration is correct, but some other system is not working along?

falconindy · 2012-05-22 23:17:11

You configured idmapd, but is it actually running?

davidovitch · 2012-05-23 07:45:02

Yeah, when I went over it again this morning I suddenly realized I might have forgotten the obvious...I'll have to check it tonight when back at home. I think the reason why I might dismissed that was because at the Arch Wiki page on NFSv4 it is actually disputed whether or not any NFS modules need to be running. But I should update that wiki page with more correct information I suppose.

Thanks for your suggestion!

davidovitch · 2012-05-23 21:04:18

And indeed...rpcbind and nfs-common where not running on the client...stupid.
However, I only got the permissions the right when setting Nobody user on the client as the home user:

[Mapping]
Nobody-User = myhomeusername
Nobody-Group = myhomegroup

As far as I understand it, now I just force to have any unresolved mappings mapped to homeuser/homegroup on the client. I was under the impression that the /etc/exports on the server was supposed to make sure the file ownership was preserved on the client. The only other thing I can think of is that although the UID number is the same on both client and server, the UID name is not. I suppose both UID name and number need to be identical for a successful mapping.

Arch Linux

#1 2012-05-22 22:09:50

unexpected NFSv4 permissions behaviour

#2 2012-05-22 23:17:11

Re: unexpected NFSv4 permissions behaviour

#3 2012-05-23 07:45:02

Re: unexpected NFSv4 permissions behaviour

#4 2012-05-23 21:04:18

Re: unexpected NFSv4 permissions behaviour

Board footer