UPDATE: The following post is referring to the user-mode NFS server that some linux distributions had when I wrote the post back in 2007. Now (2013), most distro’s just use the kernel based NFS server, which does not include the uid/gid remapping as far as I am aware.
My debian etch box is a file server amongst other things and generally I
use NFS to mount its directories on other linux boxes, and as per an
earlier post I also mount these directories on the MacMini.
Generally access is read only, but I noticed my write access didn’t work
at all. I kept on getting permission denied errors. Of course, it was
because my uids and gids did not match up between client and server. Now the linux user mode NFS server (which is what I run) has a uid/gid remapping facility. I first
tried something like this in /etc/exports:
/somedir 10.1.2.0/255.255.255.0 (rw,insecure,map_static=/etc/nfs.map)
And set up my /etc/nfs.map file as :
# remote local
gid 500 1000
uid 500 2003
So that means that if the client is uid 500, that it gets remapped to
uid 2003 on the server. And gid 500 on the client gets mapped to 1000 on
I tried it and it didn’t work.
Then I read that if you use subnet matching then some stuff doesn’t
work, so attempt two using the explicit IP of one of my clients:
Stopped and started the NFS server and mounted on the client (linux at
this stage) and it all worked.
Then I added some entries into the map for the MacMini.And had my
/somedir 10.1.2.1 (rw,insecure,map_static=/etc/nfs.map)
and my new /etc/nfs.map looked like:
# remote local
gid 500 1000 # linux client
uid 500 2003 # linux client
gid 501 1000 # Mac client
uid 501 2003 # Mac client
That didn’t work. Well it worked on one of the clients, but not the
other. I think the mapping clashed, so I ended up having separate maps
for each client:
/somedir 10.1.2.1 (rw,insecure,map_static=/etc/nfs.map.linux)
And split that nfs.map file appropriately.
Now it all worked.