# [SOLVED]nfs idmap problems, nobody is owner of all files

## pgu

After a server was updated all home directories on the gentoo client gets nobody as owner. How to I debug idmap to make sure I get the right owner?Last edited by pgu on Sat Feb 18, 2012 4:54 pm; edited 1 time in total

----------

## depontius

I would make sure that idmapd is properly configured and running on both client and server.  Without that nfsv4 just isn't going to do it's job right.  If you've done an update, it's possible that it's either not running or has been de-configured on one or the other.  At a minimum make sure the "Domain =" is set right.  I also use non-standard "Nobody-User" and "Nobody-group".  I don't know that idmapd.conf needs to exactly match on client and server, but I always find it easier if they do.

----------

## pgu

The server is working as other clients seem to handle it fine.

I see that rpc.idmapd is running. And the Domain is set correctly. Other clients (e.g. CentOS) is using "NEED_IDMAPD=yes" in /etc/default/nfs-common. I've done that, but I'm uncertain if that's the way it's done in Gentoo or if the NEED_IDMAPD is passed in /etc/conf.d/nfs or elsewhere? The latter has a NFS_NEEDED_SERVICES="rpc.idmapd" which is I assume is causing rpc.idmapd to start.

----------

## LinuxTom

Hello,

I have a problem that does not work for me the user and group mapping. See the configuration and log files here.

Configurationfile /etc/idmapd.conf for server and client:

```
#~ grep -v '^#' /etc/idmapd.conf | grep -v '^$'

[General]

Verbosity = 10

Domain = localdomain

Pipefs-Directory = /var/lib/nfs/rpc_pipefs

[Mapping]

Nobody-User = vdr

Nobody-Group = vdr

[Translation]

 

[Static]

[UMICH_SCHEMA]

LDAP_server = ldap-server.local.domain.edu

LDAP_base = dc=local,dc=domain,dc=edu
```

Can anyone give me a hint?

----------

## pgu

I tried to do a world update and installed kernel 3.2.1, but the only thing that happened is that the NFS automounter stopped working   :Sad: 

If I NFS mount manually I can mount, but the group/owner of the mounted files are still not correct. So now I have two problems to fix   :Sad: 

----------

## pgu

 *pgu wrote:*   

> I tried to do a world update and installed kernel 3.2.1, but the only thing that happened is that the NFS automounter stopped working  
> 
> 

 

That was since auto.master had moved from /etc/ to /etc/autofs. So the automount of NFS works, but the idmap still does not...Last edited by pgu on Sat Feb 18, 2012 3:21 pm; edited 1 time in total

----------

## pgu

Are there any query tools which will check if the idmap is working correctly, or if the cause is that NFS does not care about idmap at all?

----------

## pgu

```
grep -i idmap .config

CONFIG_NFS_USE_NEW_IDMAPPER=y

```

So it should be in the kernel...

----------

## LinuxTom

Yes. Server and client.  :Sad: 

```
zcat /proc/config.gz | grep -i CONFIG_NFS_USE_NEW_IDMAPPER

CONFIG_NFS_USE_NEW_IDMAPPER=y

```

----------

## depontius

@pgu - One thought...

In your idmapd.conf you have "Domain = localdomain", but later on you have "LDAP_server = ldap-server.local.domain.edu".  Assuming the latter is how you've really set things up, the first line should be "Domain = local.domain.edu".

@LinuxTom - I'm not familiar with "CONFIG_NFS_USE_IDMAPPER", and I see that I don't have it set.  I'm currently running gentoo-sources-3.2.6, my nfsv4 mounts and idmapping are working correctly.  Can you give more info about this new option, or point me at something to read about it?

----------

## pgu

Hmm, maybe it's the "new" (whatever that means) idmapper which is the problem, I'll do a test without it...

----------

## pgu

```
 zcat /proc/config.gz | grep -i CONFIG_NFS_USE_NEW_IDMAPPER             

# CONFIG_NFS_USE_NEW_IDMAPPER is not set
```

Yep, that did it. Now it works   :Very Happy: 

----------

## pgu

except that now the other nfs mount shows up as nobody nobody, maybe one server is using the "new" feature set, and the other dont...

----------

## pgu

I changed it to solved as it solved my problem related to the idmap setup

----------

## depontius

 *pgu wrote:*   

> I changed it to solved as it solved my problem related to the idmap setup

 

Could you please summarize your solution.  The post before last made it sound as if you had two mounts, and were able to get one or the other to work, but not both.  I presume to call this [solved] you've got both working.  What did it take?

I've looked a bit more into CONFIG_NFS_USE_NEW_IDMAPPER and find that there's new code, and it's "activated" by a new USE flag, "nfsidmap" that is new to nfs-utils-1.2.4 and beyond.  Right now my system is at stable nfs-utils-1.2.3-r1, so it's irrelevant to me.  At this point it's worth considering moving one system to the new nfs-utils, so I can get some early experience with it.

The really interesting thing about it is that it will allow you to substitute your own name/group<->uid/gid mapping.  So-called "modern" Linux distributions don't give a lot of control over UIDs, especially the first UID after installation.  Yet with any sort of network filesystem having consistent UID/GID across the "enterprise" (for me, my home lan) is necessary.  It looks like something could be done here to allow per-system mapping.  Of course that may be opening a can of worms, and maybe one is better off with the chore of harmonizing /etc/passwd and /etc/group.  I wish current distros were better about this.

----------

## pgu

 *depontius wrote:*   

>  *pgu wrote:*   I changed it to solved as it solved my problem related to the idmap setup 
> 
> Could you please summarize your solution.  The post before last made it sound as if you had two mounts, and were able to get one or the other to work, but not both.  I presume to call this [solved] you've got both working.  What did it take?
> 
> 

 

My solution only applied to one of them, which was good enough for me.

The solution was to disable the "new" scheme. But some other partition I'm mounting seem to depend upon this "new" feature, hence now I'm getting the same problem on the other partition. However, that's not a big problem as I mount this read only and most files have read access for "other". 

But for somebody who need to mount two different servers (i.e. one "old", and one "new") with correct mappings this might be a problem. Since this appears to be a global kernel setting for the NFS client, there is no way to specify it differently for different NFS mount points.

If you don't think it was correct to mark it SOLVED, let me know and I'll revert.

----------

## depontius

So are you also saying that I'm going to need to upgrade my whole lan at the same time?  I guess I figured that idmapping was a protocol-level thing, and new-vs-old was an in-box type of thing.

Crud - this may take some experimentation.  I hate the very idea of trying to do a whole-lan all-must-work-together upgrade.  It's bad enough that MythTV is pretty much that way, but at least my backend is on a "client" machine.  I touch my servers very little.

----------

## pgu

 *depontius wrote:*   

> So are you also saying that I'm going to need to upgrade my whole lan at the same time? 

 

I think so, but I might be wrong as I'm just speculating. There might be some other solution as well. In my case I can't upgrade the whole lan as I have no control of some of the servers as they are managed by others using distros other than gentoo.

----------

## LinuxTom

Thank, this is the solution for me.  :Smile: 

----------

## depontius

Come to think of it, this doesn't ring right, to me.  From what I can tell, the whole "USE=idmapd" thing is about how the kernel talks to userspace to map between usernames and UIDs, groupnames and GIDs.  I don't believe it has anything to do with the over-the-wire protocol - that kind of thing wouldn't happen in such a minor version bump - from 1.2.3 to 1.2.4.

I would be much more inclined to compare the /etc/idmapd.conf files from the 2 servers, and see if they are consistent.  Grep out all of the comments if you have to, but I'll be there's some sort of difference there, and it might also be worth comparing /etc/passwd and /etc/group between the 2 servers.  That seems to be to be a far more likely source of "can only get one working at a time" than the mechanism of kernel<->userspace communication.

Now that it comes up, when I get time I'll have to take a system and move it to nfs-utils-1.2.5 and try this, just to be sure.

----------

## pgu

 *depontius wrote:*   

> I would be much more inclined to compare the /etc/idmapd.conf files from the 2 servers, and see if they are consistent

 

The server which I've setup might be misconfigured in some way. However, the only information found in the idmapd.conf on the two serves is basically the "Domain = " statement which contains the same domain for both servers. But there might be some differences in /etc/nsswitch which is causing this difference. When accessing local filesystems the user and group id's from NIS are correct.

----------

## LinuxTom

I have even a litte access problem. See here.

----------

## depontius

Are /etc/passwd and /etc/group between the various systems "harmonized"?  I'm not even sure if this is necessary for nfs, considering the existence of the idmapper, but I also use afs at work, and it is for that.  Therefore I've always done it on my home lan.

----------

## LinuxTom

@depontius:

For passwords or id's or both?

----------

## depontius

I'm thinking primarily about keeping UID and GID matched.  I generally match users' passwords as a matter of convenience and practicality, but I don't believe it's necessary for nfs.  If I had more time etc, I'd have LDAP/Kerberos central authentication.  I've tried a few times to do it, and bounced off.  If I were to try again these days, I'm not sure if it would be more "practically educational" to try again with OpenLDAP and either MIT or Heimdal Kerberos, or to go with something like RedHat Directory Services.  I first got into my "overgrown home lan" as a backup plan, training myself for alternate employment, a decade ago.  In the years since my job has become much more secure.

----------

## wmark

If you're using the following

```
zcat /proc/config.gz | grep -i CONFIG_NFS_USE_NEW_IDMAPPER 

CONFIG_NFS_USE_NEW_IDMAPPER=y 
```

... then compile nfs-utils with NFSv41 support and add this line at the very top to /etc/request-key.conf:

 *Quote:*   

> create  id_resolver     *       *               /usr/sbin/nfsidmap %k %d 600

 

... or else "upcalls" won't work. You will run into error messages (and all files will be owned by 'nobody') if you have not set a domain name, yet. Please see this follow-up post on how to do that.

----------

## depontius

I just ran "make xconfig" to take a look, and it doesn't appear that NFS_USE_NEW_IDMAPPER requires NFS_V4_1.  When I look at /usr/src/linux/Documentation/filesystems/nfs/idmapper.txt I don't see anything about nfsv4.1 being required.  (To be fair, I don't see anything about nfsv4 being required, either.)  I though nfsv4.1 was primarily for larger-scale and distributed fileservers.

I thought the new idmapper was all about a more efficient way to talk between kernel and user space for id mapping.

----------

## wmark

depontius, you're right - I am wrong about the dependecy on NFSv4.1; the nfsidmap is the right USE-flag. Everything else should still be correct as long as I am not mistaken. Thanks!

Without the idmapper numerical UIDs/GIDs must match. But that configuration is prone to errors (syncing IDs, or utilizing NIS...), so I wouldn't deploy it in a network at home anymore.

----------

## depontius

 *wmark wrote:*   

> Without the idmapper numerical UIDs/GIDs must match. But that configuration is prone to errors (syncing IDs, or utilizing NIS...), so I wouldn't deploy it in a network at home anymore.

 

You mean that I don't have to keep /etc/passwd and /etc/group in sync on my home network?  That's been a royal pain in the neck, and I've been doing it for years!  Does nfsv3 use the idmapper?

----------

## LinuxTom

 *wmark wrote:*   

> If you're using the following

 

This not work. HELP ME!!

----------

## LinuxTom

How do I increase the debug level, if I do not even know if the /etc/request-key.conf is used?

----------

## skwang

I wanted to add my two cents to this thread because I had a similar problem, idmapd was not running and all my UID/GIDs were 4294967294 (2^32-2). I used the information in this thread to help me solve this problem.

My solution involved:

1. Make sure rpc.idmapd (/etc/init.d/rpc.idmapd) is running on both server and client. It was running on the server, but the I had to add it to the default runlevel on the client.

2. I set the Method to "static".  This is because I do not use LDAP or NIS, so I wound up having to manually map the users I have.

I have posted the relevant lines from my /etc/idmapd.conf here

```
[General]

Verbosity = 3

Domain = achaeans.net

[Mapping]

Nobody-User = nobody

Nobody-Group = nobody

[Translation]

Method = static

[Static]

skwang@achaeans.net = skwang

m3user@achaeans.net = m3user

```

I should point out that I have reset the verbosity to zero now that I have a working NFS. Basically in the static section I map the usernames on the NFS share to the usernames in the client. These names happens to be the same because I built this system with NFSv3 a long time ago, and recently started using NFSv4. I hope this helps anyone with a similar problem as mine.

----------

