NFS + autofs /home mount stubbornly mounting as "nobody"
 

The setup:

Two machines (currently VMs for testing purposes) with Ubuntu 10.10, one server, one desktop (in production it will be 4+ desktops)

Both configured to use LDAP for user authentication.

Desktop is running autofs, it is NOT configured to get its mount data from LDAP until I verify everything works without it. auto.home file contains
Test user's homedir copied to the server and put in exports file with rw,sync,no_root_squash,no_subtree_check

Basic idmapd.conf file set up and enabled in all nfs-common and nfs-kernel-server conf files. Nothing was changed from the defaults except filling in the Domain field.

The directory mounts correctly except that it's mounting as nobody and nogroup, and I need it to mount as the user who mounts it. I'm sure I must be one command switch away from having this right but I can't find it.

Here are some troubleshooting steps:

1. Check the file permissions on the server. Are they setup properly?

2. Mount the directory manually using the mount command to see if the file ownership shows up properly on the desktop.

3. Check the auto.master file on the server to make sure it points to the correct auto.home file.

Also, I assume 192.168.2.115 is the server's IP address. Is this correct?

As far as I can tell, yes. The test user owns the directory on the server, it owns the mount point on the desktop, they both have the usual permissions for home directories.
I added the mount to /etc/fstab with the user option and did a manual mount; it still mounts as nobody.
There's only one, and I made it, and a typo would have it just fail to mount at all, so really no chance of conflict here.
Yes. The VM doing the testing isn't in the internal DNS; can be, but isn't.

I finally found the issue, and it was in idmapd, which is practically undocumented. Adding

to idmapd.conf will tell the service to refer to nsswitch.conf to see where to get user data from. Since none of the accounts are on the local machine it doesn't know where to look otherwise.

nsswitch.conf
 

Hi ellakano,
you spotted the fact that "idmapd" is practically undocumented.
Could you please be more accurate about the way you filled your "nsswitch.conf" ?
Thanks.

nsswitch.conf is not a part of idmapd, but a part of the system authentication packages - see http://en.wikipedia.org/wiki/Name_Service_Switch and man nsswitch.conf.

If you are using the default file-based authentication methods, you'll probably never see it. If you've implemented a single sign on or other such system such as LDAP (in my case) or NIS, configuring this file is part of enabling the alternate login modules on the client system - in the case of Debian-based systems they are configured when you install the nss-related packages. There are no changes you actually make to nsswitch.conf itself that have anything to do with NFS.

The issue here is that NFS expects default authentication methods, getting its data out of /etc/passwd, /etc/group and so on. When you're using ldap authentication, your user accounts don't exist in these files. Adding the above lines to idmapd.conf tells idmapd to look at nsswitch.conf to find the correct place to get the user's id data from.

Thanks for your references.
But what are "system authentication packages" and "nss-related packages" ?
I don't use LDAP. I have a "/etc/nsswitch.conf" and its content is :
passwd: compat
group: compat
shadow: compat
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
I get "users" as the owner group, but still "nobody" as the owner user.

If you're not using LDAP, then this is not the solution you're looking for. (Nor should you want to run LDAP unless you're in a multi-user office environment).

That you have the group showing up properly means that idmapd is doing its job, but you should check that

* On both machines, your user has the same user id number
* your /etc/exports file on the server is not forcing root_squash

And in general, check your config against a guide such as https://help.ubuntu.com/community/NFSv4Howto

Thanks for the link, I know this howto, but my config is slightly different.
On both server and client the main user id is 1000 belonging to the group id 100.

On the server (192.168.1.2):
/etc/fstab:
UUID=... /mnt/Backup ext4 defaults,errors=remount-ro,relatime,async,_netdev 0 2
/etc/exports:
/mnt/Backup/subfolder 192.168.1.3(rw,no_root_squash,no_subtree_check,async)
/etc/idmapd.conf:
Domain = <server_hostname>

On the client (192.168.1.3):
/etc/auto.master:
/net /etc/auto.nfs --ghost,--timeout=30
/etc/auto.nfs
Backup -fstype=nfs4,rw,intr,async 192.168.1.2:/mnt/Backup/subfolder
/etc/idmapd.conf:
Domain = <server_hostname>

The problem is that even if I put 770 or 777 rights on /mnt/Backup/subfolder the following command fails in creating files in subfolders:
cp -alR "/net/Backup/folder1/"* "/net/Backup/folder2"
To be more accurate, /net/Backup/folder2 have 777 rights, all subfolders are created but have 555 rights, none of included files are created and one error message "operation not permitted" per each file copy attempt is displayed.

Can you see obvious any mistake ?

Are your /etc/default/nfs-common and /etc/default/nfs-kernel-server files actually set up to use idmapd? (See above howto).

I also don't know how idmapd behaves if you don't have domain name service running - I'm on an office network, so we're running DNS server internally.

Other than that, my knowledge on this subject is really pretty limited,

I don't know any parameter in /etc/default/nfs-kernel-server that is related to "idmapd".
On both server and client the following line is in /etc/default/nfs-common:
NEED_IDMAPD=yes
On both server and client, the following command returns that rpc.idmapd is running:
ps aux | grep idmapd

Please push the limits of your knowledge to suggest anything else to me...

An note to add to this thread for google searchers - we had the same issue where no matter what we did, the nfs mount would not map the user ids correctly (although this was with CentOS 6).

The issue was idmapd had cached the incorrect ids from the faulty configuration, and no fixing of the configuration would sort it.

The command on centos to fix this was nfsidmap -c (clear cache).

Hopefully this helps some desparate searcher..

Hello fellow googlers... I to found this page and nfsidmap -c also did the trick after much frustration.

So that post did help one desperate searcher :)
Ciao!