strange NFS behaviour after upgrade to F13

[Julian C. Dunn]

I have upgraded both a NFS client and NFS server to F13 from F12.

Now, on the client, all the files in my NFS home directory appear to be
owned by nobody:nobody. It's as though they were being mysteriously
root_squashed even though they're not owned by root.

Oddly enough, all read/write operations seem to work. The only reason I
noticed is because I tried to SSH to the server and ssh(1) refused to
read the $HOME/.ssh/config.

Anyone have any ideas? On the client I have:

demeter:/home	/home			nfs	defaults	0 0	

in /etc/fstab and on the server:

/home                          192.168.5.0/24(rw,sync)

in /etc/exports.

- Julian

[M A Young]

On Thu, 3 Jun 2010, Julian C. Dunn wrote:

>  I have upgraded both a NFS client and NFS server to F13 from F12.
>
>  Now, on the client, all the files in my NFS home directory appear to be
>  owned by nobody:nobody. It's as though they were being mysteriously
>  root_squashed even though they're not owned by root. 
This could be as a result of the switch from NFSv3 to NFSv4 by default. I 
have seen this problem as well though I haven't had time to investigate if 
this is the trigger.

 	Michael Young

[SPF:fail] Re: strange NFS behaviour after upgrade to F13

[Ed Greshko]

On 06/05/2010 06:34 AM, Julian C. Dunn wrote:
>  On 06/04/2010 08:15 AM, M A Young wrote:
>    
> > On Fri, 4 Jun 2010, M A Young wrote:
> >
> >     
> >> On Thu, 3 Jun 2010, Julian C. Dunn wrote:
> >>
> >>       
> >>> I have upgraded both a NFS client and NFS server to F13 from F12.
> >>>
> >>> Now, on the client, all the files in my NFS home directory appear to be
> >>> owned by nobody:nobody. It's as though they were being mysteriously
> >>> root_squashed even though they're not owned by root.
> >>>         
> >> This could be as a result of the switch from NFSv3 to NFSv4 by default. I 
> >> have seen this problem as well though I haven't had time to investigate if 
> >> this is the trigger.
> >>       
> > Are you getting a lot of error messages like
> > rpc.idmapd[pid]: nss_getpwnam: name 'user@nisdomain' does not map into 
> > domain 'dnsdomain'
> > in /var/log/messages? In my case it looks like rpc.idmapd can't cope 
> > with nisdomain and dnsdomain being different and I haven't successfully 
> > found a way to get this to work.
> >     
>  Yes, I have many of those as well -- although I am not using NIS so I
>  don't know if it's relevant.
>
>  Also, I was running NFSv4 under F12 as well.
>
>
>     
The way to fix this is to edit /etc/idmapd.conf on both the server and
client side and ensure that they have matching "Domain =" declarations. 
After editing, it is necessary to restart rpc.idmapd.

Ed


-- 
Caution: breathing may be hazardous to your health. 葛斯克 愛德華 / 台北
市八德路四段

[Julian C. Dunn]

On 06/04/2010 08:15 AM, M A Young wrote:
>  On Fri, 4 Jun 2010, M A Young wrote:
>  
> > On Thu, 3 Jun 2010, Julian C. Dunn wrote:
> >
> >> I have upgraded both a NFS client and NFS server to F13 from F12.
> >>
> >> Now, on the client, all the files in my NFS home directory appear to be
> >> owned by nobody:nobody. It's as though they were being mysteriously
> >> root_squashed even though they're not owned by root.
> >
> > This could be as a result of the switch from NFSv3 to NFSv4 by default. I 
> > have seen this problem as well though I haven't had time to investigate if 
> > this is the trigger.
>  
>  Are you getting a lot of error messages like
>  rpc.idmapd[pid]: nss_getpwnam: name 'user@nisdomain' does not map into 
>  domain 'dnsdomain'
>  in /var/log/messages? In my case it looks like rpc.idmapd can't cope 
>  with nisdomain and dnsdomain being different and I haven't successfully 
>  found a way to get this to work. 
Yes, I have many of those as well -- although I am not using NIS so I
don't know if it's relevant.

Also, I was running NFSv4 under F12 as well.

- Julian

[M A Young]

On Fri, 4 Jun 2010, M A Young wrote:

>  On Thu, 3 Jun 2010, Julian C. Dunn wrote:
>
> > I have upgraded both a NFS client and NFS server to F13 from F12.
> > 
> > Now, on the client, all the files in my NFS home directory appear to be
> > owned by nobody:nobody. It's as though they were being mysteriously
> > root_squashed even though they're not owned by root.
>
>  This could be as a result of the switch from NFSv3 to NFSv4 by default. I 
>  have seen this problem as well though I haven't had time to investigate if 
>  this is the trigger. 
Are you getting a lot of error messages like
rpc.idmapd[pid]: nss_getpwnam: name 'user@nisdomain' does not map into 
domain 'dnsdomain'
in /var/log/messages? In my case it looks like rpc.idmapd can't cope 
with nisdomain and dnsdomain being different and I haven't successfully 
found a way to get this to work.

 	Michael Young

[Julian C. Dunn]

On 06/03/2010 10:39 PM, Julian C. Dunn wrote:
>  I have upgraded both a NFS client and NFS server to F13 from F12.
>  
>  Now, on the client, all the files in my NFS home directory appear to be
>  owned by nobody:nobody. It's as though they were being mysteriously
>  root_squashed even though they're not owned by root.
>  
>  Oddly enough, all read/write operations seem to work. The only reason I
>  noticed is because I tried to SSH to the server and ssh(1) refused to
>  read the $HOME/.ssh/config.
>  
>  Anyone have any ideas? On the client I have:
>  
>  demeter:/home	/home			nfs	defaults	0 0	
>  
>  in /etc/fstab and on the server:
>  
>  /home                          192.168.5.0/24(rw,sync)
>  
>  in /etc/exports. 
Hmm... seems like I might be the victim of a kernel bug:

IMA: unmeasured files on fsmagic: EF53
ima_dec_counts: open/free imbalance (r:1 w:-1 o:0)
Pid: 1292, comm: nfsd Not tainted 2.6.33.5-112.fc13.x86_64 #1
Call Trace:
 [<ffffffff811d8dc8>] ima_file_free+0x1e2/0x1f6
 [<ffffffff8110295f>] __fput+0x135/0x1d7
 [<ffffffff81102a16>] fput+0x15/0x17
 [<ffffffffa035cb7a>] nfsd_close+0x9/0xb [nfsd]
 [<ffffffffa036e9aa>] release_open_stateid+0x3a/0x47 [nfsd]
 [<ffffffffa03718b9>] nfsd4_close+0x8c/0x112 [nfsd]
 [<ffffffffa0366a84>] nfsd4_proc_compound+0x211/0x3d2 [nfsd]
 [<ffffffffa0358365>] nfsd_dispatch+0xec/0x1c7 [nfsd]
 [<ffffffffa02e9a94>] svc_process_common+0x2b9/0x4b4 [sunrpc]
 [<ffffffffa02e9eae>] svc_process+0x121/0x135 [sunrpc]
 [<ffffffffa03588a1>] nfsd+0xf1/0x13a [nfsd]
 [<ffffffffa03587b0>] ? nfsd+0x0/0x13a [nfsd]
 [<ffffffff810643bb>] kthread+0x7a/0x82
 [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10
 [<ffffffff81064341>] ? kthread+0x0/0x82
 [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10
iint_free: readcount: 1
iint_free: writecount: -1

The filesystem fscks clean, so I guess I'll file a Bugzilla report...

- Julian