Skip to contentSkip to conversation

nfs-utils-1.1.3 released.

DISCUSSION Steve Dickson 10 participants 19 messages Jul 28, 2008 – Aug 26, 2008 4 messages not in the archive

Subsystems (2)
lore
Share & tools
lore

Steve Dickson

author Acked-by NeilBrown Acked-by Chuck Lever Acked-by Chuck Lever
#0 lore raw

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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".

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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).

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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 ",").

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.

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

commit 7ef076fb98233783843d6019b2edbb48e2d18914

Author: Oren Held <[email protected]>
Date:   Thu May 8 05:23:10 2008 -0400

Fixed smail typo in exportfs man page

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.

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]>

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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.

steved.

_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

#1 lore raw
Quoted 8 lines · Steve Dickson

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

#2 lore raw

(was: nfs-utils-1.1.3 released)

In reply to Steve Dickson
Quoted 6 lines · Steve Dickson

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

Quoted 8 lines · Christian Surchi
Quoted 7 lines · Rasmus Bøg Hansen

Package: nfs-common
Version: 1:1.1.3-1
Severity: important

Upgrading nfs-common 1:1.1.3-1 broke my NFS client.

Quoted 8 lines
Quoted 3 lines

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

_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

A message that is not in the archive (sent off-list or not yet received): 20080801131533.GN14057-ePWG1nzy00eujY+JMLXK6WCv5UukjcD9wsqeKsqY1Ps@public.gmane.org

#4 lore raw

Re: (was: nfs-utils-1.1.3 released)

Quoted 9 lines · On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Salazar = wrote:
Quoted 6 lines · Steve Dickson

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.

Quoted 5 lines

=20
Please read the Debian bug report at http://bugs.debian.org/492970
=20

Quoted 1 line · Christian Surchi

On Wed, Jul 30, 2008 at 12:56:12PM +0200, Rasmus B=C3=B8g Hansen wro=

te:

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

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

Quoted 1 line
Quoted 1 line
Quoted 1 line

the client to 1:1.1.3-1 access to my files (/home is NFS-mounted) i=

s

Quoted 1 line
Quoted 1 line
Quoted 1 line

disallowed where it should be allowed (and certainly was in 1:1.1.2=

-6).

Quoted 12 lines
Quoted 5 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#6 lore raw

Re: (was: nfs-utils-1.1.3 released)

Quoted 1 line · On Saturday August 2, [email protected] wrote:

On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salazar w=

rote:

Quoted 11 lines
Quoted 9 lines · Steve Dickson
Quoted 6 lines

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

Quoted 2 lines

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

Quoted 1 line

failing. Maybe there's some difference in the mount options? What d=

oes

Quoted 1 line

/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

#7 lore raw

Re: (was: nfs-utils-1.1.3 released)

In reply to a message not in the archive

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==

A message that is not in the archive (sent off-list or not yet received): 87myjul1fk.fsf-D7l3p2TGOOdLdt5/[email protected]

#9 lore raw

Re: (was: nfs-utils-1.1.3 released)

Quoted 3 lines · Paul Collins

"J. Bruce Fields" <[email protected]> writes:
=20

Quoted 1 line

On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Sala=

Quoted 11 lines · zar
Quoted 11 lines
Quoted 9 lines · Steve Dickson
Quoted 6 lines

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

Quoted 1 line
Quoted 1 line

itself, but here it seems the mount is succeeding and subsequent fi=

le

Quoted 1 line
Quoted 1 line

access (which I'd expect to only involve the in-kernel client code)=

is

Quoted 1 line
Quoted 1 line

failing. Maybe there's some difference in the mount options? What=

does

Quoted 3 lines
Quoted 1 line

/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

Quoted 1 line

my 1.1.2 server. I checked /proc/mounts and noticed sec=3Dnull on th=

e

Quoted 2 lines

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.

#10 lore raw

Re: (was: nfs-utils-1.1.3 released)

Quoted 37 lines · J. Bruce Fields
Quoted 29 lines · Paul Collins
Quoted 18 lines · J. Bruce Fields

On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salazar =

Quoted 9 lines · wrote:
Quoted 6 lines · Steve Dickson

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 =

Quoted 8 lines

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?

Quoted 6 lines

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.

Quoted 6 lines

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

#11 lore raw

Re: (was: nfs-utils-1.1.3 released)

Quoted 5 lines · Chuck Lever
Quoted 4 lines · J. Bruce Fields
Quoted 3 lines · Paul Collins
Quoted 1 line · J. Bruce Fields

On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Sal=

azar

Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
Quoted 20 lines
Quoted 9 lines · wrote:
Quoted 6 lines · Steve Dickson

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?

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

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

Quoted 5 lines
Quoted 5 lines
Quoted 2 lines

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!

Quoted 8 lines
Quoted 3 lines

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

A message that is not in the archive (sent off-list or not yet received): 87d4ko5wlx.fsf-D7l3p2TGOOdLdt5/[email protected]

#13 lore raw

Re: (was: nfs-utils-1.1.3 released)

Quoted 6 lines · Paul Collins
Quoted 5 lines · Chuck Lever
Quoted 4 lines · J. Bruce Fields
Quoted 3 lines · Paul Collins
Quoted 1 line · J. Bruce Fields

On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salaz=

ar

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines · wrote:
Quoted 1 line · Steve Dickson

I just cut the 1.1.3 nfs-utils release. Unfortunately I'm havin=

g

Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 17 lines
Quoted 7 lines
Quoted 5 lines

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?

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

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

Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 3 lines

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?

Quoted 6 lines
Quoted 4 lines

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.

Quoted 3 lines

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

#14 lore raw

Bug#492970: (was: nfs-utils-1.1.3 released)

Quoted 7 lines · Chuck Lever
Quoted 6 lines · Paul Collins
Quoted 5 lines · Chuck Lever
Quoted 4 lines · J. Bruce Fields
Quoted 3 lines · Paul Collins
Quoted 1 line · J. Bruce Fields

On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Salaz=

ar

Quoted 37 lines
Quoted 37 lines
Quoted 37 lines
Quoted 28 lines
Quoted 21 lines
Quoted 11 lines
Quoted 9 lines · wrote:
Quoted 6 lines · Steve Dickson

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.

Quoted 9 lines

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?

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 3 lines
Quoted 3 lines

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

#15 lore raw

Re: (was: nfs-utils-1.1.3 released)

Quoted 63 lines · On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
Quoted 48 lines · Chuck Lever
Quoted 47 lines · Paul Collins
Quoted 46 lines · Chuck Lever
Quoted 36 lines · J. Bruce Fields
Quoted 28 lines · Paul Collins
Quoted 16 lines · J. Bruce Fields

On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve =

Salazar

Quoted 11 lines · wrote:
Quoted 8 lines · Steve Dickson

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.

Quoted 9 lines

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?

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

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.

Quoted 2 lines

Also, enabling NFS mount debugging messages when performing the mount that eventually doesn't work would be enlightening (for me). Either:

Quoted 7 lines

I won't be around that machine for a week or so.

Quoted 3 lines
Quoted 3 lines

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

#16 lore raw

Re:

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Chuck" == Chuck Lever <[email protected]> writes:

[skipped]

Quoted 3 lines

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).

I've seen same thing with degraded sec=none having SUSE 9SP3 nfs-utils-1.0.6-103.23 on server side and 1.1.2-3899db6d on client side, so 3c1bb23c seems causing problems.

#17 lore raw

Re: (was: nfs-utils-1.1.3 released)

Quoted 11 lines · Sergey Bolshakov
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Chuck" == Chuck Lever <[email protected]> writes:

[skipped]

Quoted 4 lines

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).

I've seen same thing with degraded sec=none having SUSE 9SP3 nfs-utils-1.0.6-103.23 on server side and 1.1.2-3899db6d on client side, so 3c1bb23c seems causing problems.

That's plausible. The patch description claims the new client shouldn't choose AUTH_NULL even if it's in the list, so there may be a bug in the logic introduced by 3c1bb23c.

The new nfs(5) man page says sec=sys is the default if no security flavor is explicitly specified. This is incorrect (or an oversimplification at the very least), given the security negotiation that goes on in mount.nfs. That's another bug that should be fixed when this problem is addressed.

I doubt similar security flavor negotiation occurs in the kernel's mountd client, in the text-based case; thus the default sec=sys is always used when no security flavor is specified. That's probably yet another bug.

I'm still at a loss to explain how this would show up on 2.6.26 clients. mount.nfs from nfs-utils-1.1.1 and beyond on that kernel should be using the text-based interface, so changing nfs-utils shouldn't have any effect on this behavior.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

#18 lore raw

Bug#492970: (was: nfs-utils-1.1.3 released)

In reply to Chuck Lever
Quoted 32 lines · Chuck Lever
Quoted 31 lines · On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
Quoted 30 lines · Chuck Lever
Quoted 29 lines · Paul Collins
Quoted 28 lines · Chuck Lever
Quoted 27 lines · J. Bruce Fields
Quoted 26 lines · Paul Collins
Quoted 23 lines · J. Bruce Fields
Quoted 10 lines · On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve =20 Salazar wrote:
Quoted 7 lines · Steve Dickson

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?

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

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

Quoted 33 lines
Quoted 33 lines
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 9 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 3 lines
Quoted 3 lines

Whichever one it was, the problem was present with 1.1.3 installed, and
not present with 1.1.2 installed.

Quoted 5 lines
Quoted 1 line

Same here.

Thanks for the report.

In addition to the debugging mentioned above, anyone encountering this =

=20

Quoted 2 lines

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

--=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

#19 lore raw

Re: Bug#492970: (was: nfs-utils-1.1.3 released)

Quoted 99 lines · Lucas Nussbaum
Quoted 90 lines · Chuck Lever
Quoted 81 lines · On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
Quoted 60 lines · Chuck Lever
Quoted 59 lines · Paul Collins
Quoted 57 lines · Chuck Lever
Quoted 44 lines · J. Bruce Fields
Quoted 42 lines · Paul Collins
Quoted 30 lines · J. Bruce Fields
Quoted 8 lines · An=EDbal Monsalve Salazar

On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson =

Quoted 5 lines · 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:

Quoted 4 lines
Quoted 2 lines

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 =

Quoted 1 line

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 =

Quoted 7 lines
Quoted 1 line

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?

Quoted 7 lines
Quoted 1 line

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.

Quoted 6 lines

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.

Quoted 7 lines
Quoted 5 lines
Quoted 5 lines

Whichever one it was, the problem was present with 1.1.3 =

installed,
and
not present with 1.1.2 installed.

Same here.

Quoted 7 lines

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).

Quoted 7 lines

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.

Quoted 22 lines

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.

Quoted 5 lines

Tested the server/client combination against the previous versions, as well as Solaris and FreeBSD.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

#20 lore raw

Re: Bug#492970: (was: nfs-utils-1.1.3 released)

Quoted 124 lines · Chuck Lever
Quoted 105 lines · Lucas Nussbaum
Quoted 96 lines · Chuck Lever
Quoted 87 lines · On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
Quoted 66 lines · Chuck Lever
Quoted 65 lines · Paul Collins
Quoted 63 lines · Chuck Lever
Quoted 50 lines · J. Bruce Fields
Quoted 42 lines · Paul Collins
Quoted 32 lines · J. Bruce Fields
Quoted 7 lines · An=EDbal Monsalve Salazar

On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson =

Quoted 3 lines · 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 =

Quoted 7 lines
Quoted 5 lines

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 =

Quoted 1 line

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 =

Quoted 6 lines

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.

Quoted 7 lines

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?

Quoted 7 lines
Quoted 1 line

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.

Quoted 6 lines

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.

Quoted 7 lines
Quoted 5 lines
Quoted 5 lines

Whichever one it was, the problem was present with 1.1.3 =

installed,
and
not present with 1.1.2 installed.

Same here.

Quoted 7 lines

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).

Quoted 7 lines

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 =

Quoted 7 lines

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

#21 lore raw

Re: Bug#492970: (was: nfs-utils-1.1.3 released)

Quoted 4 lines · Chuck Lever

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.