idmapping with nfs4 mounts not working in feisty

[Sebastian Stark]

Binary package hint: nfs-common

I have an edgy and a feisty box. It is possible to mount stuff with nfs3 from/to each other. When I try nfs4 it also mounts correctly but the remapping of userids does not fully work. This problem exists when I export on feisty and mount on edgy as well as the other way round.

The userid being 501 and 1000 on the other system respectively, idmapd seems to correctly translate between the two hosts. I can check with ls(1) and see the correct (translated) username. But when I try to write data I get permission denied.

I am pretty sure this is a uid mapping problem because I can write data on the nfs4 share as root when I export with no_root_squash.

idmapd.conf on both systems is identical, with Domain set to "local".

exports looks like this on both systems:

  /export 192.168.1.0/24(rw,fsid=0,sync,no_subtree_check) 127.0.0.1/8(rw,fsid=0,sync,no_subtree_check)
  /export/data 192.168.1.0/24(rw,nohide,sync,no_subtree_check) 127.0.0.1/8(rw,nohide,sync,no_subtree_check)

Mount has been done with the following command:

  mount -t nfs4 otherhost:/ /import/otherhost

Can somebody confirm this?

[Patrik Pira (papira)]

I also have problem with id mapping on Gutsy, but if I restart rpc.idmapd on the exporting server a while after bootup id-mapping works. Some dependency problem at startup? I haven't had the time to dig deeper into it yet...

[Charles Elwood (charles-technomancer)]

I have the same problem as Patrik.
Every time my server boots I have to restart nfs-common in order for idmapd to work properly.
It appears to be independent of mount attempts from clients.
I have been using the same NFS4 setup since dapper with no problems until gutsy, it's pretty simple, one server provides nis, NFS4 shares to both nis clients and one client that doesn't use nis. All clients are affected.

#/etc/exports on server
/export 192.168.2.0/24(rw,sync,wdelay,no_subtree_check,fsid=0)
/export/mythtv 192.168.2.0/24(rw,sync,wdelay,no_subtree_check,nohide)
/export/nishome 192.168.2.0/24(rw,sync,wdelay,no_subtree_check,nohide,no_root_squash)

# In /etc/default/nfs-common
# An old habit, but autodetection has been problematic
NEED_IDMAPD=yes

# /etc/idmapd.conf
# Same on all local systems
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
# I think this needs to be my NIS domain
Domain = mordor.local

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = nsswitch

[Greg Randall (greg-teamgadget)]

I have the same issue and have recreated it by building a couple fresh servers. After reboot, I noticed rpc.idmapd is running but when a client mounts the nfs4 export, the permissions are "nobody,nogroup". It's like it is not running. To get around this bug, I simply restart nfs-common which is a pain in the butt.

sudo /etc/init.d/nfs-common restart

I'm wondering if the order of services loading is the issue? Should we be starting the nfs-common and nfs-kernel-server server later? I'll give it a try and get back with my results

[Greg Randall (greg-teamgadget)]

Nope didn't work. The problem must be in nfs-common

[Martin von Gagern (gagern)]

Same problem with correct mapping for file listings but denied write access here in hardy, after avoiding bug #235930, which by the way might be useful for people who get "nobody,nogroup" mappings.

Running "rpc.idmapd -fvvv" on both machines showed me that id mapping was done from server numeric ids to names to client numeric ids, but apparently not the other way round. I haven't understood nfs4 enough to judge whether or not this is expected behaviour. I guess I'd need to read more of rfc 3530, as I can't fathom yet where in my wiresharked network traffic all this user authentication is supposed to happen.

[Martin von Gagern (gagern)]

On my net the same users have different numeric IDs on different machines. While id mapping takes care of this for the file ownership attribute, it won't work for user authentication for sec=sys mounted systems as I had hoped. So even though the files get displayed with correct user names on both ends, the server may think you a different person, most probably "nobody". I found out about this in mail archives:
http://thread.gmane.org/gmane.linux.nfsv4/466
http://thread.gmane.org/gmane.linux.nfsv4/7103/focus=7105

On the whole, this issue seems to be a whishlist item for NFS (v5?), but not an actual bug in Ubuntu. I have to say that the complete lack of a comprehensive error message makes it quite difficult to understand, though.

[gogh (gogh)]

Any news on this bug?

I still have the problem more than 1 year later. The only workaround which is working for me is the one reported by Patrick : restarting rpc.idmapd on server side after bootup.

My server is Hardy and client is Interpid.