I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
issues accessing my kernel.org account so for the moment the
tar ball is only available on SourceForge:
http://sourceforge.net/projects/nfs
As usual the tree is at:
git://linux-nfs.org/nfs-utils
Here is the change log for this release:
commit 7f6ca07a8836dbdf30a227580441b99607639fd4
Author: Martin Leisner <[email protected]>
Date: Fri Jul 25 14:50:06 2008 -0400
showmount issues
The connect_nb() routne returns zero for success and a negative
value for failure which was not being interpreted correctly
by the getport() routine. This patch fixes that problem.
Signed-off-by: Steve Dickson <[email protected]>
commit eddfbf7ac8ecd3f17dc295df6c1dac4bbc6ca846
Author: Chuck Lever <[email protected]>
Date: Fri Jul 25 14:31:18 2008 -0400
nfs(5) man page: Add documentation for the "mountproto=" option
Looks like mountproto= was never documented in nfs(5). Add a paragraph
that describes it in the "nfs mount options" section.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit cf8a5cbe7f6e6ae546c3e48710b657e3d940c7fb
Author: Steve Dickson <[email protected]>
Date: Fri Jul 25 14:15:47 2008 -0400
sm-notify: perform DNS lookup in the background.
If an NFS server has no network connectivity when it reboots,
it will block in sm-notify waiting for DNS lookup for a potentially
large number of hosts. This is not helpful and just annoys the
sysadmin.
So do the DNS lookup in the backgrounded phase of sm-notify,
before sending off the NOTIFY requests.
Acked-by: NeilBrown <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit ba8dd9533e647b70d6e46beed3dcd8d8036b02af
Author: Neil Brown <[email protected]>
Date: Wed Jul 16 13:28:52 2008 -0400
If portmap is not listening on UDP (as apparently happens with
MS-Windows-Server2003R2SP2), then nfs mounts have to be mounted
with -o mountproto=tcp to succeed.
In this case a umount will still try UDP and will fail to contact the
server. It will still succeed with the local unmount (after a
timeout) but exits with a non-zero exit status. This causes
/bin/mount to retry so we get a strange error about the filesystem
not being mounted.
So:
get umount to use tcp if "mountproto=tcp" appears in mtab
ignore any failure message from the server that would overwrite
a success message from the local umount syscall.
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 8508942e7244017325690e2d0c17429fa0cb9873
Author: Neil Brown <[email protected]>
Date: Wed Jul 16 13:15:46 2008 -0400
If an NFS server is only listening on TCP for portmap (as apparently
MS-Windows-Server2003R2SP2 does), mount doesn't cope. There is retry
logic in case the initial choice of version/etc doesn't work, but it
doesn't cope with mountd needing tcp.
So:
Fix probe_port so that a TIMEDOUT error doesn't simply abort
but probes with other protocols (e.g. tcp).
Fix rewrite_mount_options to extract the mountproto option before
doing a probe, then set mountproto (and mount prot) based
on the result.
Signed-off-by: Neil Brown <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 8e158aa65577b96494eaa94c4983eed1449116dc
Author: Steve Dickson <[email protected]>
Date: Tue Jul 15 14:43:00 2008 -0400
It appears that a recent glibc update now enforces the requirement for a mode
parameter for open calls with the O_CREAT flag set. nfs-utils support code
defines a function xflock used by exportfs and mountd that calls open with
O_CREAT but no mode parameter. This causes exportfs and mountd to dump core,
with the error message:
*** invalid open64 call: O_CREAT without mode ***:rpc.mountd terminated
Signed-off-by: Steve Dickson <[email protected]>
commit 8dfb9661a132a206c10067f40e274cf797dab1b2
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:59:00 2008 -0400
Clean up: Include the bare minimum of legacy RPC headers in
utils/mount/network.h.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 1a1d3757d8881000496b838ff7d1ede981e9c40d
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:57:10 2008 -0400
Clean up: remove unneeded headers from utils/mount/stropts.c.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 93cfabb56a0b85cffca9c75cfac59e687157d0cc
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:55:36 2008 -0400
Clean up: rename a couple of functions in utils/mount/stropts.c to match
the naming convention of the others.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit abb44f59bd004112a217011a2560dd7c7f94b5a2
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:53:50 2008 -0400
Clean up: remove unused IPv4-only functions used by the text-based mount
command.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 1d61a1116198714f50b081daecc663625124403d
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:51:07 2008 -0400
Traditionally the mount command has looked for a ":" to separate the
server's hostname from the export path in the mounted on device name,
like this:
mount server:/export /mounted/on/dir
The server's hostname is "server" and the export path is "/export".
You can also substitute a specific IPv4 network address for the server
hostname, like this:
mount 192.168.0.55:/export /mounted/on/dir
Raw IPv6 addresses present a problem, however, because they look something
like this:
fe80::200:5aff:fe00:30b
Note the use of colons.
To get around the presence of colons, copy the Solaris convention used for
raw NFS server IPv6 addresses, which is to wrap the raw IPv6 address with
square brackets. This is also suggested in RFC 4038.
Introduce a new device name parser that can support traditional device
names and square brackets. Place the parser in a separate source file
so both the mount and umount paths can derive the server's hostname and
export pathname the same way.
Bonus points: add a check for NFS URLs and display an appropriate error
message in that case. This is cleaner than failing with "unknown host:
nfs".
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 586a66451679e25c47cb8cd65a0c6a0c44148920
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:38:53 2008 -0400
Change the fix_mounthost_option() function to support resolving IPv6
addresses.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 313dcf93f7a8351ff1664a3a7e2a964e02ea624a
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:37:07 2008 -0400
Change the append_clientaddr_option() function to support sending either
IPv4 or IPv6 addresses to the kernel via the "clientaddr=" option.
If the mount.nfs4 command can't determine an appropriate callback address,
it used to fail the mount request. This new function simply sends an ANY
address instead, so the mount request succeeds, but delegation is disabled.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 1adb0e018f57079c6e95a9bdbf904361354b0527
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:34:49 2008 -0400
Change the append_addr_option() function to support sending either IPv4
or IPv6 addresses to the kernel via the "addr=" option.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit da8a62dc65d2d105a3304dd41b6bdae5a5ddc742
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:33:32 2008 -0400
There are three helpers that convert sockaddr-style addresses to text
addresses, then construct mount options to pass these addresses to the
kernel. The tail of each of these helpers does exactly the same thing,
so introduce a helper that handles the common code.
Magically, the new helper supports IPv6 as well as IPv4.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 6ab9cdacd2ea314a837c7affb840aeeec620cb66
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:31:17 2008 -0400
Introduce IPv6-enabled version of get_client_address. The legacy mount
command could use this eventually as well.
If this new function fails to discover an appropriate callback address, it
fills in an ANY address to indicate to the server that it should not call the
client back (ie delegations are disabled in this case).
The user can specify a callback address via the clientaddr= mount option in
this case to enable delegation.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit ffb42f63d41542bd2dab4570248d18642e39ed48
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:27:15 2008 -0400
Introduce two new functions to convert a sockaddr to a presentation format
string and back.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 0ff226cb9dc9382c5215368a03a5bd3a69ee287a
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:23:58 2008 -0400
Add #include directives for additional header files needed to support IPv6
networking. This is a separate patch so subsequent
patches can be reordered without collision.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 20db952fc211b3444d83049f2d127da4f3ca6989
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 13:20:01 2008 -0400
We want to continue to support building nfs-utils on systems that do not
have IPv6-enabled RPC libraries and headers installed, so add a
./configure switch that allows distros to disable IPv6 functionality.
This patch introduces the nfs-utils autotools configuration to the library
and header dependencies that will be required in subsequent patches.
Later patches can then be reordered more easily if these new dependencies
are added in one heap.
For now, --enable-ipv6 defaults to "no", so this patch should not result in
any behavioral changes to the nfs-utils build process, by default.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 8bca04ebcc345784bf2ef29f0781e66157d76558
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 12:17:19 2008 -0400
Currently the "-s" option is ignored by the text-based mount interface. To
notify the kernel that sloppy mount option parsing is needed, add "sloppy"
to the string of mount options passed to the kernel.
The 2.6.23 - 2.6.26 kernels will fail the mount if "sloppy" is present, as
they won't recognize it. To prevent them from ever seeing this option,
have the mount command check the kernel version before appending the option.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 46c6575fe23a7468c17ec3329d956e9d3afe60e8
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 12:15:29 2008 -0400
Lots of parts of nfs-utils already depend on getaddrinfo(3).
We could find each instance where getaddrinfo(3) is invoked, wrap it with
'#ifdef HAVE_GETADDRINFO', and provide equivalent logic without it, but that's
a whole lot of work... and no-one has complained about this so far.
So as a clean-up, let's simply add a hard dependency for it in configure.ac,
and call it a day.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 1ca49510fd1742955330583f259db7faf501a5e5
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 12:13:10 2008 -0400
Clean up: add the traditional pre-processor safety check in headers under
utils/mount to prevent them from being included multiple times.
For headers that already have this, use a more unique macro name to reduce the
probability that some other header may use the same macro.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit d5a09b59916d4ef24b15e34eac394149cb7a641a
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 12:10:33 2008 -0400
Moved the kernel version-ing code into a new version.h
header file which allows the code to be shared
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 4f101548ef4990979400b7095e199c30204b100a
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 12:02:42 2008 -0400
Introduce a new DNS resolver function in utils/mount/network.c that uses
getaddrinfo(3), which supports AF_INET6, to resolve host names.
Replace the guts of nfs_gethostbyname() with a call to the new function.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 52fe32278aee9f359d4ef6d1fab7be405ca0b193
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 11:59:03 2008 -0400
The text-based mount command displays the rather inexplicable "mount:
internal error" whenever it encounters a problem that is entirely
unexpected by its designers.
Let's beef that error message up to include instructions about reporting
the problem, and fix the error code returned by the mount option rewriting
logic so that also will no longer report "internal error". An error in there
should generally only occur if there was an invalid mount option specified.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 191d129672dacdc3ae3ac165cd1f2a877529d0ad
Author: Chuck Lever <[email protected]>
Date: Tue Jul 15 11:56:13 2008 -0400
Updated both the mountstats and nfs-iostat scripts to used the
proper abbreviation for kilobytes per second (kB/s).
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 58080798db321d025143df39c97f707ea994ba26
Author: Christiaan Welvaart <[email protected]>
Date: Tue Jul 15 11:42:42 2008 -0400
Ported the create_mtab() routine from util-linux-ng as well
some add_mtab() updates to better hand the instances where
/etc/mtab does not exist or is not writable
Signed-off-by: Christiaan Welvaart <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit afa859b029d9cd15604ce7d5f88b5a205ea4c774
Author: Lukas Hejtmanek <[email protected]>
Date: Tue Jul 15 10:12:39 2008 -0400
The rpc.gssd scans for any suitable kerberos ticket. In cross-realm
environment this may not be the desired behaviour. Therefore a new
option, -R preferred realm, is presented so that the rpc.gssd prefers tickets
from this realm. By default, the default realm is preferred.
Signed-off-by: Lukas Hejtmanek <[email protected]>
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 1e1c7be98749fff054beec4bf67b436b58f6edac
Author: Lukas Hejtmanek <[email protected]>
Date: Tue Jul 15 10:07:45 2008 -0400
The default expiration of kernel gss contexts is the expiration
of the Kerberos ticket used in its creation. (For contexts
created using the Kerberos mechanism.) Thus kdestroy has
no effect in nullifying the kernel context.
This patch adds -t <timeout> option to rpc.gssd so that the client's
administrator may specify a timeout for expiration of contexts in kernel.
After this timeout, rpc.gssd is consulted to create a new context.
By default, timeout is 0 (i.e., no timeout at all) which follows the
previous behavior.
Signed-off-by: Lukas Hejtmanek <[email protected]>
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit b13f13b0f2ebdadc47eef8bf3fd4eb076e144fda
Author: Lukas Hejtmanek <[email protected]>
Date: Tue Jul 15 10:02:49 2008 -0400
gssd_setup_krb5_user_gss_ccache must return an error if no usable cache is
found. Trying to use invalid default cache and continue is not good idea at all.
Signed-off-by: Lukas Hejtmanek <[email protected]>
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 710765a87d599d95de51b79202ba3d82fd03ed95
Author: Steve Dickson <[email protected]>
Date: Wed Jun 25 09:23:45 2008 -0400
When a FQDN exists in /var/lib/nfs/rmtab it causes
the exportfs command to seg fault due to the nfs_export pointer
not being allocated. Reworking the parentheses in rmtab_read()
so the htype variable is evaluated correctly fix the problem.
Signed-off-by: Steve Dickson <[email protected]>
commit 2ef57222b10a91f4b96a06808d05a47e8f4c14f7
Author: Tom Talpey <[email protected]>
Date: Mon Jun 23 12:57:29 2008 -0400
Add RDMA as a supported transport for reporting
the mountstats statistics
Signed-off-by: Tom Talpey <[email protected]>
Acked-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit ba18e469a8507befdf8969c5ce7a25564744ae01
Author: Chuck Lever <[email protected]>
Date: Mon Jun 23 12:56:14 2008 -0400
The "nfs-iostat" utility is a Python program that extracts and displays NFS
client performance information from /proc/self/mountstats.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 589a913e42476a965b686c9f2656b786eaae399e
Author: Tom Talpey <[email protected]>
Date: Mon Jun 23 12:54:08 2008 -0400
Add RDMA as a supported transport for reporting the
mountstats statistics
Signed-off-by: Tom Talpey <[email protected]>
Acked-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit c761709ad3abb9c36a68c269f78118bf49d79639
Author: Chuck Lever <[email protected]>
Date: Mon Jun 23 12:52:33 2008 -0400
The "mountstats" utility is a Python program that extracts and displays NFS
client performance information from /proc/self/mountstats.
Note that if mountstats is named 'ms-nfsstat' or 'ms-iostat' it offers
slightly different functionality. It needs two man pages and the install
script should provide both commands by installing the script and providing the
other command via a symlink.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 5be04020788598cb811e51c4b1342cf0796cbb65
Author: Jeff Layton <[email protected]>
Date: Mon Jun 23 07:21:52 2008 -0400
The nfsstat program reads /proc/net/rpc/* files to gets info about
calls. This info is output as unsigned numbers (at least on any
relatively recent kernel). When nfsstat prints these numbers, they are
printed as signed integers. When the call counters reach 2^31, things
start being printed as negative numbers.
This patch changes nfsstat to read and print all counters as unsigned
integers. Tested by hacking up a kernel to initialize call counters to
2^31+1.
Thanks to Takafumi Miki for the initial version of this patch.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit c6acce67dce1cf89742a6bc4635c1eeda82e9591
Author: Steve Dickson <[email protected]>
Date: Fri Jun 6 17:27:23 2008 -0400
Removed the initialization of args2 in xlog_backend. It
caused a compilation error on x86_64 archs.
Signed-off-by: Steve Dickson <[email protected]>
commit d03090be4f440d70328988e9f792f3bd0ebd956b
Author: Neil Brown <[email protected]>
Date: Fri Jun 6 15:17:55 2008 -0400
nfsstat -m lists all current nfs mounts, with the mount options.
It does this by reading /proc/mounts and looking for mounts of type
"nfs". It really should check for "nfs4" as well.
For simplicity, just check the first 3 characters of the type.
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 52dff26c60c07cf1b4fbf8fbd3a1eab7ba90405f
Author: Chuck Lever <[email protected]>
Date: Fri Jun 6 15:07:24 2008 -0400
Fix error reporting when probe_bothports() fails while rewriting mount
options.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit c641800eb0fcaa819199e58e5c4c8d1c2a9dab5d
Author: Chuck Lever <[email protected]>
Date: Fri Jun 6 15:06:21 2008 -0400
Clean up: instead of passing so many arguments to all the helpers, have
nfsmount_string build a data structure that contains all the arguments, and
pass a pointer to that instead.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit d7a1070383bcf40d32c7f10e535ba443209dedef
Author: Chuck Lever <[email protected]>
Date: Fri Jun 6 15:02:18 2008 -0400
Steinar Gunderson reports:
"It seems retry= is now additive with the text-based mount interface. In
particular, "mount -o retry=0" still gives a two-minute timeout."
Correct the bug and make retry= option parsing more robust. If parsing
the retry option fails, the option is ignored and a default timeout is
used.
Note that currently the kernel parser ignores the "retry=" option if the
value is a number. If the value contains other characters, the kernel will
choke. A subsequent patch to the kernel will allow any characters as the
value of the retry option (excepting of course ",").
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 331c2ca949d5b4b4d18d0aca90afb8ae9475bcd6
Author: Neil Brown <[email protected]>
Date: Fri Jun 6 14:59:21 2008 -0400
Make the text-based mount path check whether statd is running if the "lock"
option is in effect. This echoes similar logic in the legacy mount path.
Signed-off-by: Neil Brown <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit fd54675db0806e81c17ee7e7eec0abfcd33f1f23
Author: Steve Dickson <[email protected]>
Date: Fri Jun 6 14:44:48 2008 -0400
Cleaned up warnings in rmtab.c and xlog.c
Signed-off-by: Steve Dickson <[email protected]>
commit 7ef076fb98233783843d6019b2edbb48e2d18914
Author: Oren Held <[email protected]>
Date: Thu May 8 05:23:10 2008 -0400
Fixed smail typo in exportfs man page
Signed-off-by: Steve Dickson <[email protected]>
commit 0930b25ee3a1eb28b957cdc70c9a1958812d895f
Author: NeilBrown <[email protected]>
Date: Thu May 8 05:18:25 2008 -0400
If mount.nfs is not installed setuid, an attempt to perform a "user"
or "users" mount will fail with a fairly obscure error message,
typically about getting "permission denied" from the server.
This patch gives a more helpful message in that case.
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 25cd5f9101b8969f9e1f9d7d486f11c215d0eeb4
Author: Vince Busam <[email protected]>
Date: Wed May 7 15:24:53 2008 -0400
Kerberos credentials may be stored in multiple places. Make it
possible to search several directories for valid credentials when
making NFS requests.
Original patch from Vince Busam <[email protected]>
Signed-off-by: Kevin Coffman <[email protected]>.
Signed-off-by: Steve Dickson <[email protected]>
commit 73f9b4402ec6625618967f947c99e6e417322d36
Author: Kevin Coffman <[email protected]>
Date: Wed May 7 14:38:47 2008 -0400
Add a new function to retrieve the current verbosity level
so that some messages that would otherwise always print may
be silenced.
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 313ab396c04afe160ee6764e28b5e61ce19c46d9
Author: Kevin Coffman <[email protected]>
Date: Wed May 7 14:32:45 2008 -0400
Add the other two DES encryption types to the default list of
Kerberos encryption types that may be negotiated.
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit a04f8b5a3ea94b7a9d96d339b6ccde5f2e67a2d1
Author: Olga Kornievskaia <[email protected]>
Date: Wed May 7 10:54:51 2008 -0400
Check the info file nfs/rpc_pipefs/nfs/clnt?/info to
see if a port number was supplied. If so, use it rather
than the default port number.
Signed-off-by: Olga Kornievskaia <[email protected]>
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 5fb4042ce4eb4fd5e50e3fb0f78bbd20b4d46e78
Author: Jeff Layton <[email protected]>
Date: Wed May 7 10:37:40 2008 -0400
The prev_bg_host stuff made sense when NFS didn't have its own mount
handler. Now though, each mount.nfs invocation is really a one-shot
affair, and this check no longer works. It also leaked memory. Remove
it.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 281ca299724f24e7b19c1eca04bba03410e2a306
Author: Jeff Layton <[email protected]>
Date: Wed May 7 10:35:30 2008 -0400
The bg option is essentially ignored with nfs4 currently. nfs4mount()
will never exit with EX_BG, so the mount will never be backgrounded.
Fix it so that when bg is specified that we error out with EX_BG as
soon as possible after the first failed mount attempt.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 5f7cc524008a7dc548a71f4c7b0d39759371a37a
Author: Jeff Layton <[email protected]>
Date: Wed May 7 10:27:53 2008 -0400
Currently nfs4mount() sets the retry value to 10000 on both fg and bg
mounts. It should be 2 for fg and 10000 for bg. nfsmount() sets it
properly, but there is a potential corner case. If someone explicitly
sets retry=10000 on a fg mount, then it will be reset to 2.
Fix this by having retry default to -1 for both flavors, and then reset if
needed after the mount options have been parsed.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit ad1fc3feae447685a8ec8c7db0ad913fe3c4de5c
Author: Sten Spans <[email protected]>
Date: Mon May 5 14:04:58 2008 -0400
Fixed arguments to the hosts_ctl() call in the good_client() routine
used in the tcpwrapper support.
Signe-off-by: Steve Dickson <[email protected]>
commit 697e28939b7d0a3e0ffe3b6bd516213a55f5a063
Author: Jeff Layton <[email protected]>
Date: Mon Apr 14 09:03:13 2008 -0400
Change how mount.nfs handles EACCES errors. Currently,
EACCES is a non-fatal error which means the mount will be
retied. This caused mounts to hang for 2mins when the client
does not have permission to access the export. In a strict
interpretation, the error that should be returned is EPERM, but
this is not always the case. So due to the fuzzy interpretation,
of EPERM and EACCES, EACCESS is now a fatal error
Signed-off-by: Steve Dickson <[email protected]>
commit 7d9dcf303b30aeb8b3dc06616d42a8abbdc61b27
Author: Li Yewang <[email protected]>
Date: Wed Apr 9 13:39:20 2008 -0400
Correct a spelling error in a mount.nfs error message
Signed-off-by: Li Yewang <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
commit 3899db6d602901523d6db6e2280c3bffd6c9ed63
Author: Steve Dickson <[email protected]>
Date: Tue Mar 18 09:34:58 2008 -0400
Make sure showmount fails when rpc.mountd is not registered
Signed-off-by: Steve Dickson <[email protected]>
commit fa29d7a9a3d8a72b79924d28813eef7e55a25bc9
Author: Steve Dickson <[email protected]>
Date: Tue Mar 18 09:33:44 2008 -0400
Updated exportfs man to talk about /var/lib/nfs/etab
instead of /var/lib/nfs/xtab
Signed-off-by: Steve Dickson <[email protected]>
commit 3c1bb23c0379864722e79d19f74c180edcf2c36e
Author: bc Wong <[email protected]>
Date: Tue Mar 18 09:30:44 2008 -0400
There were 2 things wrong with auth flavour ordering:
- Mountd used to advertise AUTH_NULL as the first flavour on
the list, which means that it prefers AUTH_NULL to anything
else (as per RFC 2623 section 2.7).
- Mount.nfs used to scan the returned list in reverse order,
and stopping at the first AUTH_NULL or AUTH_SYS encountered.
If a server advertises (AUTH_SYS, AUTH_NULL), it will by
default choose AUTH_NULL and have degraded access.
I've fixed mount.nfs to scan from the beginning. For mountd,
it does not advertise AUTH_NULL anymore. This is necessary
to avoid backward compatibility issue. If AUTH_NULL appears
in the list, either the new or the old client will choose
that over AUTH_SYS.
Tested the server/client combination against the previous
versions, as well as Solaris and FreeBSD.
Signed-off-by: bc Wong <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
steved.
_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
Steve Dickson wrote:
> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
> issues accessing my kernel.org account so for the moment the
> tar ball is only available on SourceForge:
>
> http://sourceforge.net/projects/nfs
>
> As usual the tree is at:
> git://linux-nfs.org/nfs-utils
The 1.1.3 tarball is now in http://www.kernel.org/pub/linux/utils/nfs
steved.
_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Fri, Aug 08, 2008 at 09:06:46PM -0400, Chuck Lever wrote:
>Confirmed. The kernel's mountd client doesn't even bother to
>unmarshal the auth flavor list in the server's reply.
>
>I'll work on a fix.
Please let me know when you have a patch to test it.
Chuck Lever <[email protected]> writes:
> On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
>> Chuck Lever <[email protected]> writes:
>>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>>> "J. Bruce Fields" <[email protected]> writes:
>>>>>
>>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Salaz=
ar
>>>>>> wrote:
>>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
>>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>>> tar ball is only available on SourceForge:
>>>>>>>>
>>>>>>>> http://sourceforge.net/projects/nfs
>>>>>>>> [...]
>>>>>>>
>>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>>
>>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>>> mount
>>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>>> file
>>>>>> access (which I'd expect to only involve the in-kernel client
>>>>>> code) is
>>>>>> failing. Maybe there's some difference in the mount options?
>>>>>> What does
>>>>>> /proc/self/mounts say? I assume these are all v2 or v3 mounts?
>>>>>
>>>>> I discovered today that I was no longer able to write to the v3
>>>>> mount on
>>>>> my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull on
>>>>> the
>>>>> mount. Either adding sec=3Dsys to the client's mount options or
>>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>>
>>>> That would do it!
>>>>
>>>> So it sounds like there's a bug that causes mount.nfs to get the
>>>> default
>>>> mount options wrong?
>>>
>>> I'm not sure I'm following this. I can't think of a user-space
>>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>>
>>> Paul, which kernel are you running on your clients?
>>
>> Either 2.6.26 or 2.6.27-rc1+. I'll double-check.
>
> It would be interesting if you could try both. I suspect 2.6.26
> doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount
> parser that affect "sec=3D".
I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
machine.
> Also, enabling NFS mount debugging messages when performing the mount
> that eventually doesn't work would be enlightening (for me). Either:
I won't be around that machine for a week or so.
>> Whichever one it was, the problem was present with 1.1.3 installed,
>> and
>> not present with 1.1.2 installed.
Same here.
Regards
/Rasmus
--=20
Rasmus B=C3=B8g Hansen
MSC Aps
B=C3=B8gesvinget 8
2740 Skovlunde
44 53 93 66
On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
> Chuck Lever <[email protected]> writes:
>> On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
>>> Chuck Lever <[email protected]> writes:
>>>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>>>> "J. Bruce Fields" <[email protected]> writes:
>>>>>>
>>>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve =
>>>>>>> Salazar
>>>>>>> wrote:
>>>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm =
>>>>>>>>> having
>>>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>>>> tar ball is only available on SourceForge:
>>>>>>>>>
>>>>>>>>> http://sourceforge.net/projects/nfs
>>>>>>>>> [...]
>>>>>>>>
>>>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>>>
>>>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>>>> mount
>>>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>>>> file
>>>>>>> access (which I'd expect to only involve the in-kernel client
>>>>>>> code) is
>>>>>>> failing. Maybe there's some difference in the mount options?
>>>>>>> What does
>>>>>>> /proc/self/mounts say? I assume these are all v2 or v3 mounts?
>>>>>>
>>>>>> I discovered today that I was no longer able to write to the v3
>>>>>> mount on
>>>>>> my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull on
>>>>>> the
>>>>>> mount. Either adding sec=3Dsys to the client's mount options or
>>>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>>>
>>>>> That would do it!
>>>>>
>>>>> So it sounds like there's a bug that causes mount.nfs to get the
>>>>> default
>>>>> mount options wrong?
>>>>
>>>> I'm not sure I'm following this. I can't think of a user-space
>>>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>>>
>>>> Paul, which kernel are you running on your clients?
>>>
>>> Either 2.6.26 or 2.6.27-rc1+. I'll double-check.
>>
>> It would be interesting if you could try both. I suspect 2.6.26
>> doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount
>> parser that affect "sec=3D".
>
> I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
> machine.
>
>> Also, enabling NFS mount debugging messages when performing the mount
>> that eventually doesn't work would be enlightening (for me). Either:
>
> I won't be around that machine for a week or so.
>
>>> Whichever one it was, the problem was present with 1.1.3 installed,
>>> and
>>> not present with 1.1.2 installed.
>
> Same here.
Thanks for the report.
In addition to the debugging mentioned above, anyone encountering this =
regression can also try a git bisect on nfs-utils (between 1.1.2 and =
1.1.3).
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On 06/08/08 at 12:21 -0400, Chuck Lever wrote:
> On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
>> Chuck Lever <[email protected]> writes:
>>> On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
>>>> Chuck Lever <[email protected]> writes:
>>>>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>>>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>>>>> "J. Bruce Fields" <[email protected]> writes:
>>>>>>>
>>>>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve =20
>>>>>>>> Salazar
>>>>>>>> wrote:
>>>>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately=20
>>>>>>>>>> I'm having
>>>>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>>>>> tar ball is only available on SourceForge:
>>>>>>>>>>
>>>>>>>>>> http://sourceforge.net/projects/nfs
>>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>>>>
>>>>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>>>>> mount
>>>>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>>>>> file
>>>>>>>> access (which I'd expect to only involve the in-kernel client
>>>>>>>> code) is
>>>>>>>> failing. Maybe there's some difference in the mount options?
>>>>>>>> What does
>>>>>>>> /proc/self/mounts say? I assume these are all v2 or v3 mounts?
>>>>>>>
>>>>>>> I discovered today that I was no longer able to write to the v3
>>>>>>> mount on
>>>>>>> my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull o=
n
>>>>>>> the
>>>>>>> mount. Either adding sec=3Dsys to the client's mount options or
>>>>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>>>>
>>>>>> That would do it!
>>>>>>
>>>>>> So it sounds like there's a bug that causes mount.nfs to get the
>>>>>> default
>>>>>> mount options wrong?
>>>>>
>>>>> I'm not sure I'm following this. I can't think of a user-space
>>>>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>>>>
>>>>> Paul, which kernel are you running on your clients?
>>>>
>>>> Either 2.6.26 or 2.6.27-rc1+. I'll double-check.
>>>
>>> It would be interesting if you could try both. I suspect 2.6.26
>>> doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount
>>> parser that affect "sec=3D".
>>
>> I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
>> machine.
>>
>>> Also, enabling NFS mount debugging messages when performing the mount
>>> that eventually doesn't work would be enlightening (for me). Either:
>>
>> I won't be around that machine for a week or so.
>>
>>>> Whichever one it was, the problem was present with 1.1.3 installed,
>>>> and
>>>> not present with 1.1.2 installed.
>>
>> Same here.
>
> Thanks for the report.
>
> In addition to the debugging mentioned above, anyone encountering this =
=20
> regression can also try a git bisect on nfs-utils (between 1.1.2 and =20
> 1.1.3).
Hi,
Some more info on this:
The problem only arises when the debian specific patch
debian/patches/05-default-use-old-mount-interface.patch is applied.
(it works fine with stock 1.1.3)
git bisecting with that patch applied shows that the first bad commit is:
commit 3c1bb23c0379864722e79d19f74c180edcf2c36e
Author: bc Wong <[email protected]>
Date: Tue Mar 18 09:30:44 2008 -0400
There were 2 things wrong with auth flavour ordering:
- Mountd used to advertise AUTH_NULL as the first flavour on
the list, which means that it prefers AUTH_NULL to anything
else (as per RFC 2623 section 2.7).
- Mount.nfs used to scan the returned list in reverse order,
and stopping at the first AUTH_NULL or AUTH_SYS encountered.
If a server advertises (AUTH_SYS, AUTH_NULL), it will by
default choose AUTH_NULL and have degraded access.
=20
I've fixed mount.nfs to scan from the beginning. For mountd,
it does not advertise AUTH_NULL anymore. This is necessary
to avoid backward compatibility issue. If AUTH_NULL appears
in the list, either the new or the old client will choose
that over AUTH_SYS.
=20
Tested the server/client combination against the previous
versions, as well as Solaris and FreeBSD.
=20
Signed-off-by: bc Wong <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
--=20
| Lucas Nussbaum
| [email protected] http://www.lucas-nussbaum.net/ |
| jabber: [email protected] GPG: 1024D/023B3F4F |
--=20
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]=
.org
On Aug 7, 2008, at 11:05 AM, Lucas Nussbaum wrote:
> On 06/08/08 at 12:21 -0400, Chuck Lever wrote:
>> On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
>>> Chuck Lever <[email protected]> writes:
>>>> On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
>>>>> Chuck Lever <[email protected]> writes:
>>>>>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>>>>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>>>>>> "J. Bruce Fields" <[email protected]> writes:
>>>>>>>>
>>>>>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve
>>>>>>>>> Salazar
>>>>>>>>> wrote:
>>>>>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson =
>>>>>>>>>> wrote:
>>>>>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately
>>>>>>>>>>> I'm having
>>>>>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>>>>>> tar ball is only available on SourceForge:
>>>>>>>>>>>
>>>>>>>>>>> http://sourceforge.net/projects/nfs
>>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>>>>>
>>>>>>>>> Very weird--it might make sense if upgrading nfs-utils broke =
>>>>>>>>> the
>>>>>>>>> mount
>>>>>>>>> itself, but here it seems the mount is succeeding and =
>>>>>>>>> subsequent
>>>>>>>>> file
>>>>>>>>> access (which I'd expect to only involve the in-kernel client
>>>>>>>>> code) is
>>>>>>>>> failing. Maybe there's some difference in the mount options?
>>>>>>>>> What does
>>>>>>>>> /proc/self/mounts say? I assume these are all v2 or v3 =
>>>>>>>>> mounts?
>>>>>>>>
>>>>>>>> I discovered today that I was no longer able to write to the v3
>>>>>>>> mount on
>>>>>>>> my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull =
>>>>>>>> on
>>>>>>>> the
>>>>>>>> mount. Either adding sec=3Dsys to the client's mount options or
>>>>>>>> downgrading to nfs-common 1.1.2 on the client fixes the =
>>>>>>>> problem.
>>>>>>>
>>>>>>> That would do it!
>>>>>>>
>>>>>>> So it sounds like there's a bug that causes mount.nfs to get the
>>>>>>> default
>>>>>>> mount options wrong?
>>>>>>
>>>>>> I'm not sure I'm following this. I can't think of a user-space
>>>>>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>>>>>
>>>>>> Paul, which kernel are you running on your clients?
>>>>>
>>>>> Either 2.6.26 or 2.6.27-rc1+. I'll double-check.
>>>>
>>>> It would be interesting if you could try both. I suspect 2.6.26
>>>> doesn't exhibit this problem, as 27-rc1 has changes in the NFS =
>>>> mount
>>>> parser that affect "sec=3D".
>>>
>>> I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
>>> machine.
>>>
>>>> Also, enabling NFS mount debugging messages when performing the =
>>>> mount
>>>> that eventually doesn't work would be enlightening (for me). =
>>>> Either:
>>>
>>> I won't be around that machine for a week or so.
>>>
>>>>> Whichever one it was, the problem was present with 1.1.3 =
>>>>> installed,
>>>>> and
>>>>> not present with 1.1.2 installed.
>>>
>>> Same here.
>>
>> Thanks for the report.
>>
>> In addition to the debugging mentioned above, anyone encountering =
>> this
>> regression can also try a git bisect on nfs-utils (between 1.1.2 and
>> 1.1.3).
>
> Hi,
>
> Some more info on this:
>
> The problem only arises when the debian specific patch
> debian/patches/05-default-use-old-mount-interface.patch is applied.
> (it works fine with stock 1.1.3)
OK, that makes it more clear that the presenting problem is in the =
legacy mount.nfs path, and explains why perhaps the reporters were =
finding this problem on late model kernels that should be using the =
text-based interface.
The text-based interface is probably not correct either, but is using =
a default setting that avoids this problem, rather than negotiating =
based on the server's list.
I'll have to get off my butt and look at the kernel's mountd client to =
verify this.
> git bisecting with that patch applied shows that the first bad =
> commit is:
> commit 3c1bb23c0379864722e79d19f74c180edcf2c36e
> Author: bc Wong <[email protected]>
> Date: Tue Mar 18 09:30:44 2008 -0400
>
> There were 2 things wrong with auth flavour ordering:
> - Mountd used to advertise AUTH_NULL as the first flavour on
> the list, which means that it prefers AUTH_NULL to anything
> else (as per RFC 2623 section 2.7).
> - Mount.nfs used to scan the returned list in reverse order,
> and stopping at the first AUTH_NULL or AUTH_SYS encountered.
> If a server advertises (AUTH_SYS, AUTH_NULL), it will by
> default choose AUTH_NULL and have degraded access.
>
> I've fixed mount.nfs to scan from the beginning. For mountd,
> it does not advertise AUTH_NULL anymore. This is necessary
> to avoid backward compatibility issue. If AUTH_NULL appears
> in the list, either the new or the old client will choose
> that over AUTH_SYS.
>
> Tested the server/client combination against the previous
> versions, as well as Solaris and FreeBSD.
>
> Signed-off-by: bc Wong <[email protected]>
> Signed-off-by: Steve Dickson <[email protected]>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Aug 7, 2008, at 12:29 PM, Chuck Lever wrote:
> On Aug 7, 2008, at 11:05 AM, Lucas Nussbaum wrote:
>> On 06/08/08 at 12:21 -0400, Chuck Lever wrote:
>>> On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
>>>> Chuck Lever <[email protected]> writes:
>>>>> On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
>>>>>> Chuck Lever <[email protected]> writes:
>>>>>>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>>>>>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>>>>>>> "J. Bruce Fields" <[email protected]> writes:
>>>>>>>>>
>>>>>>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve
>>>>>>>>>> Salazar
>>>>>>>>>> wrote:
>>>>>>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson =
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately
>>>>>>>>>>>> I'm having
>>>>>>>>>>>> issues accessing my kernel.org account so for the moment =
>>>>>>>>>>>> the
>>>>>>>>>>>> tar ball is only available on SourceForge:
>>>>>>>>>>>>
>>>>>>>>>>>> http://sourceforge.net/projects/nfs
>>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>>>>>>
>>>>>>>>>> Very weird--it might make sense if upgrading nfs-utils =
>>>>>>>>>> broke the
>>>>>>>>>> mount
>>>>>>>>>> itself, but here it seems the mount is succeeding and =
>>>>>>>>>> subsequent
>>>>>>>>>> file
>>>>>>>>>> access (which I'd expect to only involve the in-kernel client
>>>>>>>>>> code) is
>>>>>>>>>> failing. Maybe there's some difference in the mount options?
>>>>>>>>>> What does
>>>>>>>>>> /proc/self/mounts say? I assume these are all v2 or v3 =
>>>>>>>>>> mounts?
>>>>>>>>>
>>>>>>>>> I discovered today that I was no longer able to write to the =
>>>>>>>>> v3
>>>>>>>>> mount on
>>>>>>>>> my 1.1.2 server. I checked /proc/mounts and noticed =
>>>>>>>>> sec=3Dnull on
>>>>>>>>> the
>>>>>>>>> mount. Either adding sec=3Dsys to the client's mount options or
>>>>>>>>> downgrading to nfs-common 1.1.2 on the client fixes the =
>>>>>>>>> problem.
>>>>>>>>
>>>>>>>> That would do it!
>>>>>>>>
>>>>>>>> So it sounds like there's a bug that causes mount.nfs to get =
>>>>>>>> the
>>>>>>>> default
>>>>>>>> mount options wrong?
>>>>>>>
>>>>>>> I'm not sure I'm following this. I can't think of a user-space
>>>>>>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>>>>>>
>>>>>>> Paul, which kernel are you running on your clients?
>>>>>>
>>>>>> Either 2.6.26 or 2.6.27-rc1+. I'll double-check.
>>>>>
>>>>> It would be interesting if you could try both. I suspect 2.6.26
>>>>> doesn't exhibit this problem, as 27-rc1 has changes in the NFS =
>>>>> mount
>>>>> parser that affect "sec=3D".
>>>>
>>>> I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
>>>> machine.
>>>>
>>>>> Also, enabling NFS mount debugging messages when performing the =
>>>>> mount
>>>>> that eventually doesn't work would be enlightening (for me). =
>>>>> Either:
>>>>
>>>> I won't be around that machine for a week or so.
>>>>
>>>>>> Whichever one it was, the problem was present with 1.1.3 =
>>>>>> installed,
>>>>>> and
>>>>>> not present with 1.1.2 installed.
>>>>
>>>> Same here.
>>>
>>> Thanks for the report.
>>>
>>> In addition to the debugging mentioned above, anyone encountering =
>>> this
>>> regression can also try a git bisect on nfs-utils (between 1.1.2 and
>>> 1.1.3).
>>
>> Hi,
>>
>> Some more info on this:
>>
>> The problem only arises when the debian specific patch
>> debian/patches/05-default-use-old-mount-interface.patch is applied.
>> (it works fine with stock 1.1.3)
>
> OK, that makes it more clear that the presenting problem is in the =
> legacy mount.nfs path, and explains why perhaps the reporters were =
> finding this problem on late model kernels that should be using the =
> text-based interface.
>
> The text-based interface is probably not correct either, but is =
> using a default setting that avoids this problem, rather than =
> negotiating based on the server's list.
>
> I'll have to get off my butt and look at the kernel's mountd client =
> to verify this.
Confirmed. The kernel's mountd client doesn't even bother to =
unmarshal the auth flavor list in the server's reply.
I'll work on a fix.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Fri, Aug 08, 2008 at 09:06:46PM -0400, Chuck Lever wrote:
> Confirmed. The kernel's mountd client doesn't even bother to
> unmarshal the auth flavor list in the server's reply.
>
> I'll work on a fix.
By the way, the server side is also kinda dumb here--it just returns a
fixed status list regardless of what security is set on the export.
This isn't hard to fix--I'm just debugging some patches.
--b.
On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
>issues accessing my kernel.org account so for the moment the
>tar ball is only available on SourceForge:
>
> http://sourceforge.net/projects/nfs
>[...]
1.1.3 clients don't work with a 1.0.10 server anymore.
Please read the Debian bug report at http://bugs.debian.org/492970
On Fri, Aug 01, 2008 at 02:54:02PM +0200, Christian Surchi wrote:
>On Wed, Jul 30, 2008 at 12:56:12PM +0200, Rasmus B?g Hansen wrote:
>>Package: nfs-common
>>Version: 1:1.1.3-1
>>Severity: important
>>
>>
>>Upgrading nfs-common 1:1.1.3-1 broke my NFS client.
>>
>>The NFS server is running etch and nothing was changed. After upgrading
>>the client to 1:1.1.3-1 access to my files (/home is NFS-mounted) is
>>disallowed where it should be allowed (and certainly was in 1:1.1.2-6).
>
>I confirm this one on my sid client too. No changes in nfs server
>(etch). Downgrading nfs-common solved the problem for me too.
>
>Christian
On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Salazar =
wrote:
> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
> >I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
> >issues accessing my kernel.org account so for the moment the=20
> >tar ball is only available on SourceForge:
> >
> > http://sourceforge.net/projects/nfs
> >[...]=20
>=20
> 1.1.3 clients don't work with a 1.0.10 server anymore.
Very weird--it might make sense if upgrading nfs-utils broke the mount
itself, but here it seems the mount is succeeding and subsequent file
access (which I'd expect to only involve the in-kernel client code) is
failing. Maybe there's some difference in the mount options? What doe=
s
/proc/self/mounts say? I assume these are all v2 or v3 mounts?
--b.
>=20
> Please read the Debian bug report at http://bugs.debian.org/492970
>=20
> On Fri, Aug 01, 2008 at 02:54:02PM +0200, Christian Surchi wrote:
> >On Wed, Jul 30, 2008 at 12:56:12PM +0200, Rasmus B=C3=B8g Hansen wro=
te:
> >>Package: nfs-common
> >>Version: 1:1.1.3-1
> >>Severity: important
> >>
> >>
> >>Upgrading nfs-common 1:1.1.3-1 broke my NFS client.
> >>
> >>The NFS server is running etch and nothing was changed. After upgra=
ding
> >>the client to 1:1.1.3-1 access to my files (/home is NFS-mounted) i=
s
> >>disallowed where it should be allowed (and certainly was in 1:1.1.2=
-6).
> >
> >I confirm this one on my sid client too. No changes in nfs server=20
> >(etch). Downgrading nfs-common solved the problem for me too.
> >
> >Christian
> _______________________________________________
> NFSv4 mailing list
> [email protected]
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Saturday August 2, [email protected] wrote:
> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salazar w=
rote:
> > On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
> > >I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
> > >issues accessing my kernel.org account so for the moment the=20
> > >tar ball is only available on SourceForge:
> > >
> > > http://sourceforge.net/projects/nfs
> > >[...]=20
> >=20
> > 1.1.3 clients don't work with a 1.0.10 server anymore.
>=20
> Very weird--it might make sense if upgrading nfs-utils broke the moun=
t
> itself, but here it seems the mount is succeeding and subsequent file
> access (which I'd expect to only involve the in-kernel client code) i=
s
> failing. Maybe there's some difference in the mount options? What d=
oes
> /proc/self/mounts say? I assume these are all v2 or v3 mounts?
I'm guessing v4 and that idmapd is causing problems. I cannot see any
other possible cause (not that this one seems likely).
If we can get a "tcpdump -s0 -port 2049" of the traffic it might help.
NeilBrown
IkouIEJydWNlIEZpZWxkcyIgPGJmaWVsZHNAZmllbGRzZXMub3JnPiB3cml0ZXM6Cgo+IE9uIEZy
aSwgQXVnIDAxLCAyMDA4IGF0IDExOjE1OjMzUE0gKzEwMDAsIEFuw61iYWwgTW9uc2FsdmUgU2Fs
YXphciB3cm90ZToKPj4gT24gTW9uLCBKdWwgMjgsIDIwMDggYXQgMDM6MTM6MTlBTSAtMDQwMCwg
U3RldmUgRGlja3NvbiB3cm90ZToKPj4gPkkganVzdCBjdXQgdGhlIDEuMS4zIG5mcy11dGlscyBy
ZWxlYXNlLiBVbmZvcnR1bmF0ZWx5IEknbSBoYXZpbmcKPj4gPmlzc3VlcyBhY2Nlc3NpbmcgbXkg
a2VybmVsLm9yZyBhY2NvdW50IHNvIGZvciB0aGUgbW9tZW50IHRoZSAKPj4gPnRhciBiYWxsIGlz
IG9ubHkgYXZhaWxhYmxlIG9uIFNvdXJjZUZvcmdlOgo+PiA+Cj4+ID4gICAgIGh0dHA6Ly9zb3Vy
Y2Vmb3JnZS5uZXQvcHJvamVjdHMvbmZzCj4+ID5bLi4uXSAKPj4gCj4+IDEuMS4zIGNsaWVudHMg
ZG9uJ3Qgd29yayB3aXRoIGEgMS4wLjEwIHNlcnZlciBhbnltb3JlLgo+Cj4gVmVyeSB3ZWlyZC0t
aXQgbWlnaHQgbWFrZSBzZW5zZSBpZiB1cGdyYWRpbmcgbmZzLXV0aWxzIGJyb2tlIHRoZSBtb3Vu
dAo+IGl0c2VsZiwgYnV0IGhlcmUgaXQgc2VlbXMgdGhlIG1vdW50IGlzIHN1Y2NlZWRpbmcgYW5k
IHN1YnNlcXVlbnQgZmlsZQo+IGFjY2VzcyAod2hpY2ggSSdkIGV4cGVjdCB0byBvbmx5IGludm9s
dmUgdGhlIGluLWtlcm5lbCBjbGllbnQgY29kZSkgaXMKPiBmYWlsaW5nLiAgTWF5YmUgdGhlcmUn
cyBzb21lIGRpZmZlcmVuY2UgaW4gdGhlIG1vdW50IG9wdGlvbnM/ICBXaGF0IGRvZXMKPiAvcHJv
Yy9zZWxmL21vdW50cyBzYXk/ICBJIGFzc3VtZSB0aGVzZSBhcmUgYWxsIHYyIG9yIHYzIG1vdW50
cz8KCkkgZGlzY292ZXJlZCB0b2RheSB0aGF0IEkgd2FzIG5vIGxvbmdlciBhYmxlIHRvIHdyaXRl
IHRvIHRoZSB2MyBtb3VudCBvbgpteSAxLjEuMiBzZXJ2ZXIuICBJIGNoZWNrZWQgL3Byb2MvbW91
bnRzIGFuZCBub3RpY2VkIHNlYz1udWxsIG9uIHRoZQptb3VudC4gIEVpdGhlciBhZGRpbmcgc2Vj
PXN5cyB0byB0aGUgY2xpZW50J3MgbW91bnQgb3B0aW9ucyBvcgpkb3duZ3JhZGluZyB0byBuZnMt
Y29tbW9uIDEuMS4yIG9uIHRoZSBjbGllbnQgZml4ZXMgdGhlIHByb2JsZW0uCgotLSAKUGF1bCBD
b2xsaW5zCldlbGxpbmd0b24sIE5ldyBaZWFsYW5kCgpEYWcgdmlqYW5kZWxpamsgbHVjaHRzY2hp
cCBkZSBodWlzbWVlc3RlciBpcyBkb29kCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fCk5GU3Y0IG1haWxpbmcgbGlzdApORlN2NEBsaW51eC1uZnMub3JnCmh0
dHA6Ly9saW51eC1uZnMub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9uZnN2NA==
On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
> "J. Bruce Fields" <[email protected]> writes:
>=20
> > On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Sala=
zar wrote:
> >> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
> >> >I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
> >> >issues accessing my kernel.org account so for the moment the=20
> >> >tar ball is only available on SourceForge:
> >> >
> >> > http://sourceforge.net/projects/nfs
> >> >[...]=20
> >>=20
> >> 1.1.3 clients don't work with a 1.0.10 server anymore.
> >
> > Very weird--it might make sense if upgrading nfs-utils broke the mo=
unt
> > itself, but here it seems the mount is succeeding and subsequent fi=
le
> > access (which I'd expect to only involve the in-kernel client code)=
is
> > failing. Maybe there's some difference in the mount options? What=
does
> > /proc/self/mounts say? I assume these are all v2 or v3 mounts?
>=20
> I discovered today that I was no longer able to write to the v3 mount=
on
> my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull on th=
e
> mount. Either adding sec=3Dsys to the client's mount options or
> downgrading to nfs-common 1.1.2 on the client fixes the problem.
That would do it!
So it sounds like there's a bug that causes mount.nfs to get the defaul=
t
mount options wrong?
--b.
On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>> "J. Bruce Fields" <[email protected]> writes:
>>
>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salazar =
>>> wrote:
>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
>>>>> issues accessing my kernel.org account so for the moment the
>>>>> tar ball is only available on SourceForge:
>>>>>
>>>>> http://sourceforge.net/projects/nfs
>>>>> [...]
>>>>
>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>
>>> Very weird--it might make sense if upgrading nfs-utils broke the =
>>> mount
>>> itself, but here it seems the mount is succeeding and subsequent =
>>> file
>>> access (which I'd expect to only involve the in-kernel client =
>>> code) is
>>> failing. Maybe there's some difference in the mount options? =
>>> What does
>>> /proc/self/mounts say? I assume these are all v2 or v3 mounts?
>>
>> I discovered today that I was no longer able to write to the v3 =
>> mount on
>> my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull on the
>> mount. Either adding sec=3Dsys to the client's mount options or
>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>
> That would do it!
>
> So it sounds like there's a bug that causes mount.nfs to get the =
> default
> mount options wrong?
I'm not sure I'm following this. I can't think of a user-space =
mount.nfs change in 1.1.3 that would affect the sec=3D option.
Paul, which kernel are you running on your clients?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Chuck Lever <[email protected]> writes:
> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>> "J. Bruce Fields" <[email protected]> writes:
>>>
>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Sal=
azar
>>>> wrote:
>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>> tar ball is only available on SourceForge:
>>>>>>
>>>>>> http://sourceforge.net/projects/nfs
>>>>>> [...]
>>>>>
>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>
>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>> mount
>>>> itself, but here it seems the mount is succeeding and subsequent
>>>> file
>>>> access (which I'd expect to only involve the in-kernel client
>>>> code) is
>>>> failing. Maybe there's some difference in the mount options?
>>>> What does
>>>> /proc/self/mounts say? I assume these are all v2 or v3 mounts?
>>>
>>> I discovered today that I was no longer able to write to the v3
>>> mount on
>>> my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull on =
the
>>> mount. Either adding sec=3Dsys to the client's mount options or
>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>
>> That would do it!
>>
>> So it sounds like there's a bug that causes mount.nfs to get the
>> default
>> mount options wrong?
>
> I'm not sure I'm following this. I can't think of a user-space
> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>
> Paul, which kernel are you running on your clients?
Either 2.6.26 or 2.6.27-rc1+. I'll double-check.
Whichever one it was, the problem was present with 1.1.3 installed, and
not present with 1.1.2 installed.
--=20
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
> Chuck Lever <[email protected]> writes:
>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>> "J. Bruce Fields" <[email protected]> writes:
>>>>
>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salaz=
ar
>>>>> wrote:
>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm havin=
g
>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>> tar ball is only available on SourceForge:
>>>>>>>
>>>>>>> http://sourceforge.net/projects/nfs
>>>>>>> [...]
>>>>>>
>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>
>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>> mount
>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>> file
>>>>> access (which I'd expect to only involve the in-kernel client
>>>>> code) is
>>>>> failing. Maybe there's some difference in the mount options?
>>>>> What does
>>>>> /proc/self/mounts say? I assume these are all v2 or v3 mounts?
>>>>
>>>> I discovered today that I was no longer able to write to the v3
>>>> mount on
>>>> my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull on=
=20
>>>> the
>>>> mount. Either adding sec=3Dsys to the client's mount options or
>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>
>>> That would do it!
>>>
>>> So it sounds like there's a bug that causes mount.nfs to get the
>>> default
>>> mount options wrong?
>>
>> I'm not sure I'm following this. I can't think of a user-space
>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>
>> Paul, which kernel are you running on your clients?
>
> Either 2.6.26 or 2.6.27-rc1+. I'll double-check.
It would be interesting if you could try both. I suspect 2.6.26 =20
doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount =20
parser that affect "sec=3D".
Also, enabling NFS mount debugging messages when performing the mount =20
that eventually doesn't work would be enlightening (for me). Either:
sudo sysctl -w sunrpc.nfs_debug=3D2048
or if you have the latest rpcdebug installed:
sudo rpcdebug -m nfs -s mount
Then perform the mount. Take a look in /var/log/messages for the =20
debugging messages.
And, please send the full command line of the failing mount request.
> Whichever one it was, the problem was present with 1.1.3 installed, =20
> and
> not present with 1.1.2 installed.
Gotcha.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com