Re: nfs-utils-1.1.6 released.

[Thanos Chatziathanassiou <tchatzi-nz9JlX+3IF8@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2808 bytes --]

O/H J. Bruce Fields έγραψε:
> On Wed, Apr 22, 2009 at 11:40:51AM -0400, Steve Dickson wrote:
>   
>> Thanos Chatziathanassiou wrote:
>>     
>>> Installed nfs-utils-1.1.6 and I'm facing an issue:
>>>
>>> on the server:
>>> # cat /etc/exports
>>> /opt/shared/home
>>> 192.168.99.0/255.255.255.0(rw,no_root_squash,no_subtree_check,sync)
>>>
>>> # cat /var/lib/nfs/etab
>>> /opt/shared/home   
>>> 192.168.99.0/255.255.255.0(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
>>>
>>>
>>> on the client:
>>> # cat /proc/mounts
>>> nfsip:/opt/shared/home /home nfs
>>> rw,noatime,vers=3,rsize=8192,wsize=8192,hard,intr,proto=udp,timeo=11,retrans=2,addr=nfsip
>>> 0 0
>>>
>>> however, everyone (including root) gets mapped to uid 65534 despite
>>> no_root_squash and no_all_squash...not very useful for a home directory.
>>> Is there something I'm missing ?
>>>       
>> Wow... That is very strange... 
>>     
>
> Might be worth looking at the network traffic to see if some change in
> the client or in the mountd security negotiation hasn't caused the
> client to start doing auth_null instead of auth_unix?
>
> --b.
>   
Apologies for taking so long, but I was out of the office last week.
I'm attaching a tcpdump of mounting the directory ``/vhome'' and doing a 
``touch lala'' (my very own ``foo'') in said directory, which resulted 
in access denied on the client.
It doesn't say much to me, but then again I'm certainly no expert.
>   
>> any type of failures in /var/log/messages?
>>     
Nothing obvious, at least. Just:
Apr 28 14:06:30 nfs mountd[1115]: authenticated mount request from 
192.168.99.6:637 for /opt/shared/vhome (/opt/shared/vhome)
on the server. nothing on the client.

By the way, umounting the directory on the client results in this being 
printed out to stderr:
``umount.nfs: address family not supported by DNS resolver''
which I saw in utils/mount/network.c.
It was missing a ``%s'' in the attached patch, which resulted in
``umount.nfs: address family not supported by DNS resolver (192.168.99.20)''
when added.

>>     
>>> Also tried to go back to the previous (1.1.1) nfs-utils, but after
>>> ``exportfs -ra'' the the server spit a few of those and all mounts froze
>>> nfs mountd[1115]: /var/lib/nfs/etab:1: unknown keyword "mapping=identity"
>>>       
>> I don't see a 'mapping' entry in the above 'cat /var/lib/nfs/etab'? 
>>     
me neither (?)
>> steved.
>> --
>> 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
>>     
Let me know if I can be of any assistance.


[-- Attachment #1.2: nfs.pkt --]
[-- Type: application/octet-stream, Size: 3290 bytes --]

[-- Attachment #1.3: utils-mount-network.c.patch --]
[-- Type: text/x-diff, Size: 335 bytes --]

--- network.c.orig	Mon Apr 20 20:32:50 2009
+++ network.c	Tue Apr 21 20:21:23 2009
@@ -266,7 +266,7 @@
 	*salen = 0;
 
 	if (af_hint != AF_INET) {
-		nfs_error(_("%s: address family not supported by DNS resolver\n"),
+		nfs_error(_("%s: address family not supported by DNS resolver (%s)\n"),
 				progname, hostname);
 		return 0;
 	}

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3242 bytes --]