All of lore.kernel.org
 help / color / mirror / Atom feed
* idmap problems with chown as root
@ 2014-05-01 16:21 Craig Yoshioka
  2014-05-01 16:34 ` Frank Filz
  2014-05-01 18:58 ` Steve Dickson
  0 siblings, 2 replies; 6+ messages in thread
From: Craig Yoshioka @ 2014-05-01 16:21 UTC (permalink / raw)
  To: linux-nfs

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]


This is a followup to a previous post I made.

With Frank Filz’s helpful suggestions I was able to gather better data.

problem: when using chown as root on a nfs4 filesystem on newer linux releases file owners get sets to nobody.
         the user type doesn’t seem to matter (/etc/passwd, LDAP, Samba4)

setup: Server is FreeBSD 10 system with NFSv4 share.
       Server and clients are all configured with the same idmap domain
       Network users have consistent uid/gid on server and clients
       clients with older linux releases work OK (Ubuntu 12.04, CentOS 5 and 6)
       clients with newer linux releases do not work ( Fedora 20, Ubuntu 14.04, Mint 16 )

clues:

1. working and non-working systems get to the same fchownat() system call with the same arguments (via strace).

example (identical on working and non-working client):
...
fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) = 0
close(1)                                = 0
close(2)                                = 0
close(4)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

2. working system sends NFSV4 SETATTR request with owner set to: matlab@nimgs.com and non-working as 11111 (via wireshark)


[-- Attachment #2: broken.cap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 2176 bytes --]

[-- Attachment #3: working.cap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 1848 bytes --]

[-- Attachment #4: Type: text/plain, Size: 203 bytes --]



3. I can’t rule out misconfiguration.  but I’ve configured as identically as I could, and tried a lot of small vairations. these are my current settings (the pipefs setting is the distro default)


[-- Attachment #5: broken.idmapd.conf --]
[-- Type: application/octet-stream, Size: 174 bytes --]

[General]
Verbosity = 3
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = nimgs.com

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

[Translation]
Method = nsswitch


[-- Attachment #6: working.idmap.conf --]
[-- Type: application/octet-stream, Size: 135 bytes --]

[General]

Verbosity = 4
Pipefs-Directory = /run/rpc_pipefs
Domain = nimgs.com

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[-- Attachment #7: Type: text/plain, Size: 2 bytes --]




^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: idmap problems with chown as root
  2014-05-01 16:21 idmap problems with chown as root Craig Yoshioka
@ 2014-05-01 16:34 ` Frank Filz
  2014-05-01 18:58 ` Steve Dickson
  1 sibling, 0 replies; 6+ messages in thread
From: Frank Filz @ 2014-05-01 16:34 UTC (permalink / raw)
  To: 'Craig Yoshioka', linux-nfs

There is a difference between your working and non-working idmapd.conf:

The working does not have:

[Translation]
Method = nsswitch

That may be what's catching you up.

Frank

> This is a followup to a previous post I made.
> 
> With Frank Filz's helpful suggestions I was able to gather better data.
> 
> problem: when using chown as root on a nfs4 filesystem on newer linux
> releases file owners get sets to nobody.
>          the user type doesn't seem to matter (/etc/passwd, LDAP, Samba4)
> 
> setup: Server is FreeBSD 10 system with NFSv4 share.
>        Server and clients are all configured with the same idmap domain
>        Network users have consistent uid/gid on server and clients
>        clients with older linux releases work OK (Ubuntu 12.04, CentOS 5
and 6)
>        clients with newer linux releases do not work ( Fedora 20, Ubuntu
14.04,
> Mint 16 )
> 
> clues:
> 
> 1. working and non-working systems get to the same fchownat() system call
> with the same arguments (via strace).
> 
> example (identical on working and non-working client):
> ...
> fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) = 0
> close(1)                                = 0
> close(2)                                = 0
> close(4)                                = 0
> exit_group(0)                           = ?
> +++ exited with 0 +++
> 
> 2. working system sends NFSV4 SETATTR request with owner set to:
> matlab@nimgs.com and non-working as 11111 (via wireshark)



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: idmap problems with chown as root
  2014-05-01 16:21 idmap problems with chown as root Craig Yoshioka
  2014-05-01 16:34 ` Frank Filz
@ 2014-05-01 18:58 ` Steve Dickson
  2014-05-01 19:44   ` Trond Myklebust
  1 sibling, 1 reply; 6+ messages in thread
From: Steve Dickson @ 2014-05-01 18:58 UTC (permalink / raw)
  To: Craig Yoshioka, linux-nfs



On 05/01/2014 12:21 PM, Craig Yoshioka wrote:
> 
> This is a followup to a previous post I made.
> 
> With Frank Filz’s helpful suggestions I was able to gather better data.
> 
> problem: when using chown as root on a nfs4 filesystem on newer linux releases file owners get sets to nobody.
>          the user type doesn’t seem to matter (/etc/passwd, LDAP, Samba4)
This should take care of the problem:

commit 3226c06989186d9cd60ba146df4e2898fee5047b
Author: Steve Dickson <steved@redhat.com>
Date:   Wed Apr 30 11:14:22 2014 -0400

    libnfsidmap: id_as_chars() fails zero value ids.
    
    Root has a zero value id which is valid and
    should not be mapped to nfsnobody
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

steved.
> 
> setup: Server is FreeBSD 10 system with NFSv4 share.
>        Server and clients are all configured with the same idmap domain
>        Network users have consistent uid/gid on server and clients
>        clients with older linux releases work OK (Ubuntu 12.04, CentOS 5 and 6)
>        clients with newer linux releases do not work ( Fedora 20, Ubuntu 14.04, Mint 16 )
> 
> clues:
> 
> 1. working and non-working systems get to the same fchownat() system call with the same arguments (via strace).
> 
> example (identical on working and non-working client):
> ...
> fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) = 0
> close(1)                                = 0
> close(2)                                = 0
> close(4)                                = 0
> exit_group(0)                           = ?
> +++ exited with 0 +++
> 
> 2. working system sends NFSV4 SETATTR request with owner set to: matlab@nimgs.com and non-working as 11111 (via wireshark)
> 
> 
> 
> 
> 
> 3. I can’t rule out misconfiguration.  but I’ve configured as identically as I could, and tried a lot of small vairations. these are my current settings (the pipefs setting is the distro default)
> 
> 
> 
> 
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: idmap problems with chown as root
  2014-05-01 18:58 ` Steve Dickson
@ 2014-05-01 19:44   ` Trond Myklebust
  2014-05-01 20:03     ` Craig Yoshioka
  0 siblings, 1 reply; 6+ messages in thread
From: Trond Myklebust @ 2014-05-01 19:44 UTC (permalink / raw)
  To: Steve Dickson; +Cc: Craig Yoshioka, Linux NFS Mailing List

On Thu, May 1, 2014 at 2:58 PM, Steve Dickson <SteveD@redhat.com> wrote:
>
>
> On 05/01/2014 12:21 PM, Craig Yoshioka wrote:
>>
>> This is a followup to a previous post I made.
>>
>> With Frank Filz’s helpful suggestions I was able to gather better data.
>>
>> problem: when using chown as root on a nfs4 filesystem on newer linux releases file owners get sets to nobody.
>>          the user type doesn’t seem to matter (/etc/passwd, LDAP, Samba4)
> This should take care of the problem:
>
> commit 3226c06989186d9cd60ba146df4e2898fee5047b
> Author: Steve Dickson <steved@redhat.com>
> Date:   Wed Apr 30 11:14:22 2014 -0400
>
>     libnfsidmap: id_as_chars() fails zero value ids.
>
>     Root has a zero value id which is valid and
>     should not be mapped to nfsnobody
>
>     Signed-off-by: Steve Dickson <steved@redhat.com>
>
> steved.
>>
>> setup: Server is FreeBSD 10 system with NFSv4 share.
>>        Server and clients are all configured with the same idmap domain
>>        Network users have consistent uid/gid on server and clients
>>        clients with older linux releases work OK (Ubuntu 12.04, CentOS 5 and 6)
>>        clients with newer linux releases do not work ( Fedora 20, Ubuntu 14.04, Mint 16 )
>>
>> clues:
>>
>> 1. working and non-working systems get to the same fchownat() system call with the same arguments (via strace).
>>
>> example (identical on working and non-working client):
>> ...
>> fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) = 0
>> close(1)                                = 0
>> close(2)                                = 0
>> close(4)                                = 0
>> exit_group(0)                           = ?
>> +++ exited with 0 +++
>>
>> 2. working system sends NFSV4 SETATTR request with owner set to: matlab@nimgs.com and non-working as 11111 (via wireshark)
>>
>>
>>
>>
>>
>> 3. I can’t rule out misconfiguration.  but I’ve configured as identically as I could, and tried a lot of small vairations. these are my current settings (the pipefs setting is the distro default)
>>

Does the following help on the client?

echo N >/sys/module/nfs/parameters/nfs4_disable_idmapping

-- 
Trond Myklebust

Linux NFS client maintainer, PrimaryData

trond.myklebust@primarydata.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: idmap problems with chown as root
  2014-05-01 19:44   ` Trond Myklebust
@ 2014-05-01 20:03     ` Craig Yoshioka
  2014-05-01 20:11       ` Trond Myklebust
  0 siblings, 1 reply; 6+ messages in thread
From: Craig Yoshioka @ 2014-05-01 20:03 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: Steve Dickson, Linux NFS Mailing List

> Does the following help on the client?
> 
> echo N >/sys/module/nfs/parameters/nfs4_disable_idmapping
> 

After restarting idmapd and remounting that did work.  Thanks.

It’s a good workaround until I can test the recent patch that stops mapping uid 0 to nobody.  


> -- 
> Trond Myklebust
> 
> Linux NFS client maintainer, PrimaryData
> 
> trond.myklebust@primarydata.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: idmap problems with chown as root
  2014-05-01 20:03     ` Craig Yoshioka
@ 2014-05-01 20:11       ` Trond Myklebust
  0 siblings, 0 replies; 6+ messages in thread
From: Trond Myklebust @ 2014-05-01 20:11 UTC (permalink / raw)
  To: Craig Yoshioka; +Cc: Dickson Steve, Linux NFS Mailing List


On May 1, 2014, at 16:03, Craig Yoshioka <craigyk@me.com> wrote:

>> Does the following help on the client?
>> 
>> echo N >/sys/module/nfs/parameters/nfs4_disable_idmapping
>> 
> 
> After restarting idmapd and remounting that did work.  Thanks.
> 
> It’s a good workaround until I can test the recent patch that stops mapping uid 0 to nobody.  
> 

I thought the problem was the FreeBSD server trying to idmap numeric strings and failing to do so correctly. It isn’t supposed to do that according to the NFSv4 spec.

_________________________________
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-05-01 20:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-01 16:21 idmap problems with chown as root Craig Yoshioka
2014-05-01 16:34 ` Frank Filz
2014-05-01 18:58 ` Steve Dickson
2014-05-01 19:44   ` Trond Myklebust
2014-05-01 20:03     ` Craig Yoshioka
2014-05-01 20:11       ` Trond Myklebust

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.