My ToDo list went to zero so I figured I would cut quick
minor maintenance release.
The tarball can be found at:
http://www.kernel.org/pub/linux/utils/nfs/
http://sourceforge.net/projects/nfs
The git tree is at:
git://linux-nfs.org/nfs-utils
The change log:
commit c062f45deebc20dae5eb8cdb50fb03fb1c252b47
Author: Chuck Lever <[email protected]>
Date: Sat Apr 18 09:45:46 2009 -0400
umount.nfs: Fix return value of nfs_mount_protocol()
Fix a copy-paste error introduced in nfs_mount_protocol(). It should
return an IPPROTO_ number, not an NFS version number.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 879a9b1b2bdd1160571896023d06291a611c4315
Author: Chuck Lever <[email protected]>
Date: Sat Apr 18 09:44:56 2009 -0400
umount.nfs: Use a privileged port when sending UMNT requests
Turns out we do actually need to use a privileged port for UMNT. The
Linux rpc.mountd complains if an ephemeral source port is used:
Apr 17 15:52:19 ingres mountd[2061]: refused unmount request from
192.168.0.59 for /export (/export): illegal port 60932
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 8c94296bc84f3a204f2061c0391a1d2350e4f37e
Author: Chuck Lever <[email protected]>
Date: Sat Apr 18 09:43:58 2009 -0400
support: Provide an API for creating a privileged RPC client
We needed to guarantee that some RPC programs, such as PMAP, got an
unprivileged port, to prevent exhausting the local privileged port
space sending RPC requests that don't need such privileges.
nfs_get_rpcclient() provides that feature.
However, some RPC programs, such as MNT and UMNT, require a privileged
port. So, let's provide an additional API for this that also supports
IPv6 and setting a destination port.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 41eb279c2f46ca020bc3b8d17811555f74b99d2e
Author: Benny Halevy <[email protected]>
Date: Wed Apr 15 14:16:08 2009 -0400
utils/nfsd: fix -N optarg error printout
as currently printed c is the version number, not a string char,
therefore is should be printed as %d not %c. That said, just print
optarg as %s since it might be non-numeric.
Signed-off-by: Benny Halevy <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit d4008af910ba1d527f00f8207fb3f8f5709e943d
Author: Chuck Lever <[email protected]>
Date: Wed Apr 15 12:52:48 2009 -0400
getport.c: fix non-standard C
Squelch a compiler warning in getport.c:
getport.c:65: warning: ¿static¿ is not at beginning of declaration
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit c51d826a201095fb3a7c68c3666e2b795a2b687d
Author: Chuck Lever <[email protected]>
Date: Wed Apr 15 12:38:40 2009 -0400
nfs-utils: reverse order of librpcsecgss and libgssglue checks
The check that validates the version of librpcsecgss also needs to
have libgssglue installed. Without libgssglue, ./configure complains
that it can't find rpcsecgss, even though it's installed.
It also turns out that the error message generated by pkg-config is
more complete than the one we have in aclocal/rpcsec_vers.m4, so just
let those PKG_CHECK_MODULES m4 macros use the default error message.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit b09228c86d4049b11c6ddf9284a637a211993b44
Author: Jeff Layton <[email protected]>
Date: Wed Apr 15 12:04:06 2009 -0400
nfs-utils: add IPv6 code to gssd
All of the pieces to handle IPv6 are now in place. Add IPv6-specific
code wrapped in the proper #ifdef's so that IPv6 support works when
it's enabled at build-time.
Reviewed-by: Chuck Lever <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit afba62a753549ae3c2a713b08163ab84bb622183
Author: Jeff Layton <[email protected]>
Date: Wed Apr 15 12:01:46 2009 -0400
nfs-utils: switch gssd to use standard function for getting an RPC client
We already have a common function for setting up an RPC client. That
function uses the tirpc API when tirpc is enabled and is also already
IPv6 enabled. Switch gssd to use it.
Reviewed-by: Chuck Lever <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit d9c3935de6c82cea687544c5d45d999297da141d
Author: Jeff Layton <[email protected]>
Date: Wed Apr 15 11:36:07 2009 -0400
nfs-utils: query for remote port using rpcbind instead of getaddrinfo
We already have the server's address from the upcall, so we don't really
need to look it up again, and querying the local services DB for the
port that the remote server is listening on is just plain wrong.
Use rpcbind to set the port for the program and version that we were
given in the upcall. The exception here is NFSv4. Since NFSv4 mounts
are supposed to use a well-defined port then skip the rpcbind query
for that and just set the port to the standard one (2049).
Reviewed-by: Chuck Lever <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 59189376db057ae08a710cb2b258426230f687d7
Author: Jeff Layton <[email protected]>
Date: Wed Apr 15 11:34:51 2009 -0400
nfs-utils: store the address given in the upcall for later use
The current upcall could be more efficient. We first convert the address
to a hostname, and then later when we set up the RPC client, we do a
hostname lookup to convert it back to an address.
Begin to change this by keeping the address in the clnt_info that we get
out of the upcall. Since a sockaddr has a port field, we can also
eliminate the port from the clnt_info.
Finally, switch to getnameinfo() instead of gethostbyaddr(). We'll need
to use that call anyway when we add support for IPv6.
Reviewed-by: Chuck Lever <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 4b27decace00754006d854a4bbbaa7dd305cba1c
Author: Jeff Layton <[email protected]>
Date: Wed Apr 15 10:29:04 2009 -0400
nfs-utils: make getnameinfo() required for --enable-gss
Systems that are so old that they don't have getnameinfo() in glibc are
probably also running kernels that are so old that they don't support
gssapi upcalls anyway.
Make --enable-gss dependent on the presence of the getnameinfo()
function. This allows us to reduce some conditional compilation.
Reviewed-by: Chuck Lever <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit fa5352f78533c7ad1d8603c1a4ba08fa82768e6b
Author: Steve Dickson <[email protected]>
Date: Wed Apr 8 10:26:26 2009 -0400
The --list option does not work on server stats.
The print_stats_list() routine was using the client's
stats to decide whether to display any stats. This did
not work when there was only server stats.
This patch breaks up print_stats_list into two different
routines allowing both server and clients stats to be
listed.
Signed-off-by: Steve Dickson <[email protected]>
commit 500fab45f73c0ba1bc442157ef3d7744f20e6b2a
Author: Steve Dickson <[email protected]>
Date: Wed Apr 8 09:48:58 2009 -0400
The server stats were not being updated with the
-Z options causing the stats to be incorrect.
Signed-off-by: Steve Dickson <[email protected]>
commit cb81340660112f9296205901b09c0668a480bc47
Author: Steve Dickson <[email protected]>
Date: Wed Apr 8 09:28:22 2009 -0400
Eliminate the displaying zero stats when the explicit protocol
is specified (-2, -3, -4) the -Z and or --list options.
When a particular protocol is specified and either
the -Z or --list options are used, zeros or blank lines
are echoed to the screen when there is not any NFS traffic.
This cause any useful data to be scroll off the screen.
With this patch only non-zero stats will be shown, which
makes the output of these options more condensed and
in turn more useful.
Signed-off-by: Steve Dickson <[email protected]>
commit ca8eb17798fb9b4936a38cc58fe379e9e8d379f9
Author: Kevin Constantine <[email protected]>
Date: Sat Apr 4 07:18:26 2009 -0400
nfsstat: Add --list flag
nfsstat.c: Adds the --list flag to print information in a list format
instead of the standard multi-column format
nfsstat.man: Updates the manpage to include the --list flag.
Signed-off-by: Kevin Constantine <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 524cdc4eb1663e5c10d12160e48c45dc81852568
Author: Steve Dickson <[email protected]>
Date: Sat Apr 4 06:46:09 2009 -0400
Keep the interval output quite when there is no NFS traffic.
The 'nfsstat -Z5' command continually outputs the following
when there is no NFS traffic.
Client rpc stats:
calls retrans authrefrsh
0 0 0
This patch adds code that will keep the interval output
quite so real results will not be scrolled of the screen
Signed-off-by: Steve Dickson <[email protected]>
commit d2319b9cabc67d999b16aea2077a4a3c642ec28d
Author: Kevin Constantine <[email protected]>
Date: Sat Apr 4 06:29:01 2009 -0400
nfsstat: Print diff stats every N seconds
nfsstat.c: Implements an optional "interval" argument to --sleep
nfsstat.man: Explains the use of --sleep[interval]
Reviewed-By: Greg Banks <[email protected]>
Signed-off-by: Kevin Constantine <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 70561910500556c8109ca2e5683a92ed51c82bb7
Author: Kevin Coffman <[email protected]>
Date: Fri Apr 3 15:20:09 2009 -0400
cacheio: return any original error from qword_eol
If the initial fflush() fails in qword_eol, log the failure
and return the indication of the original failure, not the
successful cover-up.
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 7de6c8c54ac195d659c8ac2d2ac01ef47c6c3ecd
Author: Kevin Coffman <[email protected]>
Date: Fri Apr 3 15:18:16 2009 -0400
svcgssd: check the return code from qword_eol() and log failures
If qword_eol() fails while writing the context information, log
an indication of the failure.
This addresses at least one cause of the intermittent, and
previously undiagnosed, problem of the server returning
GSS_S_NO_CONTEXT when a context was seemingly successfully
created and sent down to the kernel. In my case there was a
mis-match between kernel and user-land configuration resulting in
the proper kernel module not being loaded. Therefore the write
of the context failed, but was not logged by svcgssd. When the
kernel goes to find the resulting context, it was really not
there and correctly returned GSS_S_NO_CONTEXT to the client.
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit f0ed8401e854e1cbd23b2fb5dca5e88dec2df7c4
Author: Ben Myers <[email protected]>
Date: Fri Apr 3 15:13:10 2009 -0400
Mountd should use separate lockfiles
Mountd keeps file descriptors used for locks separate from
those used for io and seems to assume that the lock will
only be released on close of the file descriptor that was used
with fcntl. Actually the lock is released when any file
descriptor for that file is closed. When setexportent() is called
after xflock() he closes and reopens the io file descriptor and defeats the
lock.
This patch fixes that by using a separate file for locking, cleaning
them up when finished.
Signed-off-by: Ben Myers <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit c56152202a3000c69b87f9cb90f40166f1f21275
Author: Chuck Lever <[email protected]>
Date: Fri Apr 3 15:03:15 2009 -0400
nfs-utils: fix AC_CHECK_FUNC calls in configure.ac
AC_CHECK_FUNC and AC_CHECK_FUNCS take 3 args. Any ones beyond that are
ignored. In several places, we're passing the "action-if-not-found" in
as the 4th arg so it's being ignored.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 3724317e223d46908aac2405bbd73ea2de4f36e5
Author: Steve Dickson <[email protected]>
Date: Mon Mar 23 17:13:01 2009 -0400
In recent Fedora builds, the '-D _FORTIFY_SOURCE=2' compile
flag has been set. This cause warnings to be generated when
return values from reads/writes (and other calls) are not
checked. The patch address those warnings.
Signed-off-by: Steve Dickson <[email protected]>
commit d62365079f711b25e73522b2af380abc2a7e2788
Author: Jeff Layton <[email protected]>
Date: Mon Mar 23 08:13:01 2009 -0400
Regardless though, it's dangerous to keep invalid pointers around like
this. Later code changes may make it more likely for this problem to
occur.
Also eliminate some unneeded NULL pointer checks before freeing memory.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 38062464a09868ff579b3c3c0b43fcd550ea3c61
Author: Jeff Layton <[email protected]>
Date: Mon Mar 23 08:12:37 2009 -0400
gssd: free buffer allocated by gssd_k5_err_msg
There's no way for the caller of gssd_k5_err_msg to know whether to free
the string it returns. It can call krb5_get_error_message which returns
a string that must be freed via krb5_free_error_string. The other ways
that it can return a string require that the memory not be freed.
Deal with this by copying the string to a new buffer in all cases. Then
we can properly free the string allocated by krb5_get_error_message.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 7f1f9985cf510b087e7a817597094acba9143795
Author: Jeff Layton <[email protected]>
Date: Mon Mar 23 08:12:14 2009 -0400
gssd: NULL-terminate buffer after read in read_service_info (try #2)
Valgrind complains that we're passing an unintialized buffer to sscanf
here. The main problem seems to be that we're not ensuring that the
buffer is NULL terminated before we pass it off.
This is the second version of this patch, the first one did not increase
the buffer allocation by 1 which could have led to clobbering the next
byte on the stack if nbytes == INFOBUFLEN.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 690b2eb64e44dc96db68900dd17ea4586b51966e
Author: Jeff Layton <[email protected]>
Date: Mon Mar 23 08:11:41 2009 -0400
gssd: initialize fakeseed in prepare_krb5_rfc1964_buffer
This causes a compiler warning and also means that we're stuffing
the buffer with uninitialized junk from the stack. Other places in
this code initialize "fakeseed" to 0. Do the same here.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 1a4bbe59d5cf0684c46b329fcc765eac97dab6ba
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:42:44 2009 -0400
nfs-utils: clean up handling of libgssglue in gssd Makefile
From: Jeff Layton <[email protected]>
Make the pkgconfig check for libgssglue conditional on tirpc being
enabled. When it's disabled, the pkgconfig check for librpcsecgss will
pull in the gssglue lib and include dir automatically.
Also, make sure we include GSSGLUE_CFLAGS and the GSSGLUE_LIBS to the
appropriate places in utils/gssd/Makefile.am so that we pick up
the gssglue libs when tirpc is enabled.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 336f8bca825416082d62ef38314f3e0b7e8f5cc2
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:40:47 2009 -0400
nfs-utils: Include legacy or TI-RPC headers, not both
Data type incompatibilities between the legacy RPC headers and the
TI-RPC headers mean we can't use libtirpc with code that was compiled
against the legacy RPC headers. The definition of rpcprog_t for
example is "unsigned long" in the legacy library, but it's "uint32_t"
for TI-RPC. On 32-bit systems, these types happen to have the same
width, but on 64-bit systems they don't, making more complex data
structures that use these types in fields ABI incompatible.
Adopt a new strategy to deal with this issue. When --enable-tirpc is
set, append "-I/usr/include/tirpc" to the compilation steps. This
should cause the compiler to grab the tirpc/ headers instead of the
legacy headers. Now, for TI-RPC builds, the TI-RPC legacy functions
and the TI-RPC headers will be used. On legacy systems, the legacy
headers and legacy glibc RPC implementation will be used.
A new ./configure option is introduced to allow system integrators to
use TI-RPC headers in some other location than /usr/include/tirpc.
/usr/include/tirpc remains the default setting for this new option.
The gssd implementation presents a few challenges, but it turns out
the gssglue library is similar to the auth_gss pieces of TI-RPC. To
avoid similar header incompatibility issues, gssd now uses libtirpc
instead of libgssglue if --enable-tirpc is specified. There may be
other issues to tackle with gssd, but for now, we just make sure it
builds with --enable-tirpc.
Note also: svc_getcaller() is a macro in both cases that points to
a sockaddr field in the svc_req structure. The legacy version points
to a sockaddr_in type field, but the TI-RPC version points to a
sockaddr_in6 type field.
rpc.mountd unconditionally casts the result of svc_getcaller() to a
sockaddr_in *. This should be OK for TI-RPC as well, since rpc.mountd
still uses legacy RPC calls (provided by glibc, or emulated by TI-RPC)
to set up its listeners, and therefore rpc.mountd callers will always
be from AF_INET addresses for now.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 530abf870f5188b2bdd4a9211d7c93fb6ce68854
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:37:09 2009 -0400
configure: move IPv6 feature checks into aclocal
Clean up: for consistency with other local feature checks, move IPv6
feature checks into aclocal/
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit fd6a34c83051f82c9064963e24976bf3c47a5422
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:32:49 2009 -0400
nfs-utils: don't need extra libs to do AC_CHECK_LIBS for librpcsecgss
From: Jeff Layton <[email protected]>
The conftest should work without these extra libs being included.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 617d0ac4e51889506f3afc39f5ef686d5c0e0d15
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:31:27 2009 -0400
configure: Move rpcsecgss checking into aclocal
Clean up: Introduce two more aclocal scripts for handling rpcsecgss
dependency checking.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 767773f33c10dfeaf44ef7d6aea0946f5d9d248f
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:30:26 2009 -0400
configure: pull common nfsidmap and event checks into aclocal/
Clean up: Create an aclocal script for the nfsidmap library and
headers checks used for both --enable-gss and --enable-nfsv4.
Move libevent checks out too.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit d271666403a87e60bbdee85372b6dcf35c2975ed
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:29:18 2009 -0400
nfs-utils: replace function-specific switches with HAVE_LIBTIRPC
Instead of switching in TI-RPC-specific logic with a function-specific
switch like HAVE_CLNT_VG_CREATE, let's use the more generic
HAVE_LIBTIRPC macro everywhere.
This simplifies ./configure (always a good thing), and makes it more
clear in the source code exactly what the extra conditionally compiled
code is for.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 31c4305a67ca434ea5614f5bdb083fbe9acc2f7e
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:28:42 2009 -0400
configure: move TI-RPC checks into aclocal
Define an aclocal test for TI-RPC headers and library, and move the
TI-RPC checks earlier in our configure script so other feature checks
can use the availability of TI-RPC to decide what to do.
Since bindresvport_sa is required just for IPv6 support, move that
check to the IPv6 feature tests.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 8b40c0bf17ca3e007721085a3bb627a2abd52777
Author: Chuck Lever <[email protected]>
Date: Mon Mar 16 13:26:34 2009 -0400
configure: add defensive quoting in some function checks
Clean up: Add proper m4 quoting in macros that check for the presence
of some functions in configure.ac.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 06da4cfd46942acaaa5bd2e7933fd290701d186d
Author: Steve Dickson <[email protected]>
Date: Sun Mar 8 10:10:25 2009 -0400
Added back the some logging variables which are no
longer used but, unfortunately, they are extern-ed by
public headers files which are not under the control
of this package.
Spotted-by: Juergen Daubert <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
Let me know if I can be of any assistance.
On Tue, Apr 28, 2009 at 02:34:11PM +0300, Thanos Chatziathanassiou wrot=
e:
> O/H J. Bruce Fields =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
>> 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.
>> =20
> 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 doin=
g a =20
> ``touch lala'' (my very own ``foo'') in said directory, which resulte=
d =20
> in access denied on the client.
> It doesn't say much to me, but then again I'm certainly no expert.
You could send us a network trace for us to look at; just
tcpdump -s0 -wTMP
then do the mount, then ^C the tcpdump process, then send us the file
TMP.
--b.
O/H J. Bruce Fields έγραψε:
> On Tue, Apr 28, 2009 at 02:34:11PM +0300, Thanos Chatziathanassiou wrote:
>
>> O/H J. Bruce Fields έγραψε:
>>
>>> 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.
>>
>
> You could send us a network trace for us to look at; just
>
> tcpdump -s0 -wTMP
>
> then do the mount, then ^C the tcpdump process, then send us the file
> TMP.
>
I already did and attached it as nfs.pkt before. Is it missing something ?
> --b.
>
On Apr 28, 2009, at 7:34 AM, Thanos Chatziathanassiou wrote:
> O/H J. Bruce Fields =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
>> 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 =20
>>>> 192.168.99.0=20
>>>> /=20
>>>> 255.255.255.0=20
>>>> (rw=20
>>>> ,sync=20
>>>> ,wdelay=20
>>>> ,hide=20
>>>> ,nocrossmnt=20
>>>> ,secure=20
>>>> ,no_root_squash=20
>>>> ,no_all_squash=20
>>>> ,no_subtree_check,secure_locks,acl,anonuid=3D65534,anongid=3D65534=
)
>>>>
>>>>
>>>> on the client:
>>>> # cat /proc/mounts
>>>> nfsip:/opt/shared/home /home nfs
>>>> rw=20
>>>> ,noatime=20
>>>> ,vers=20
>>>> =3D=20
>>>> 3=20
>>>> ,rsize=20
>>>> =3D8192,wsize=3D8192,hard,intr,proto=3Dudp,timeo=3D11,retrans=3D2,=
addr=3Dnfsip
>>>> 0 0
>>>>
>>>> however, everyone (including root) gets mapped to uid 65534 despit=
e
>>>> no_root_squash and no_all_squash...not very useful for a home =20
>>>> 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 =
=20
>> 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 =20
> doing a ``touch lala'' (my very own ``foo'') in said directory, =20
> 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 =20
> 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 =20
> being printed out to stderr:
> ``umount.nfs: address family not supported by DNS resolver''
> which I saw in utils/mount/network.c.
That's a bug in nfsumount.c. I'll post a patch for it.
> It was missing a ``%s'' in the attached patch, which resulted in
> ``umount.nfs: address family not supported by DNS resolver =20
> (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 =20
>>>> mounts froze
>>>> nfs mountd[1115]: /var/lib/nfs/etab:1: unknown keyword =20
>>>> "mapping=3Didentity"
>>>>
>>> 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-=20
>>> nfs" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
> Let me know if I can be of any assistance.
>
> <nfs.pkt>--- network.c.orig Mon Apr 20 20:32:50 2009
> +++ network.c Tue Apr 21 20:21:23 2009
> @@ -266,7 +266,7 @@
> *salen =3D 0;
>
> if (af_hint !=3D AF_INET) {
> - nfs_error(_("%s: address family not supported by DNS resolver\n"),
> + nfs_error(_("%s: address family not supported by DNS resolver (%s)=
=20
> \n"),
> progname, hostname);
If you are hitting this function, then your glibc doesn't have =20
AI_ADDRCONFIG? Can you tell us what distribution this is? (And =20
perhaps which version of glibc is installed?)
(This is probably not related to your other problem, but it is =20
unexpected with a late-model 2.6.x kernel).
> return 0;
> }
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Tue, Apr 28, 2009 at 06:14:46PM +0300, Thanos Chatziathanassiou wrote:
> I already did and attached it as nfs.pkt before. Is it missing something ?
Whoops, sorry, wasn't paying attention.
So, yes, if you look at the "Remote Procedure Call"->"Credentials" on
the next-to-last packet (#25), you'll see that it's sending the CREATE
with AUTH_NULL credentials field.
So the create's going to be done with nfsnobody credentials, and won't
succeed unless it's in a world-writeable directory.
The mount reply (packet #10) is listing the flavors as: AUTH_NULL,
AUTH_UNIX, RPCSEC_GSS_KRB5, RPCSEC_GSS_KRB5I, RPCSEC_GSS_KRB5P in that
order. The client may just be choosing the first?
I seem to recall a couple bugs in this area that were fixed recently,
but can't find those now.
--b.
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...
any type of failures in /var/log/messages?
> 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'?
steved.
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.
>
> any type of failures in /var/log/messages?
>
> > 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'?
>
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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 ?
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"
Any help is greatly appreciated.