nfs-utils.git/utils/mount, branch gss-proxy-mods

NFS man page patch that moves nordirplus/rdirplus

2013-03-25T14:09:11+00:00

NFS man page patch that moves nordirplus/rdirplus from "Options for NFS
versions 2 and 3 only" to "Options supported by all versions".  Its a
better fit here since this option is also needed for some NFSv4 servers.

Signed-off-by: Chris Vogan 
Signed-off-by: Steve Dickson

mount.nfs: error message clean up.

2012-11-28T14:33:53+00:00

Remove a unnecessary newline in an error message.

Signed-off-by: Steve Dickson

mount.nfs: Continue to trying address when the server return EACCES

2012-11-28T14:33:40+00:00

With recent changes to the /etc/hosts file, the 'localhost'
host name is now multiply defined as both an IPv4 address (127.0.01)
and an IPv6 address (::1). This causes first address returned
by getaddrinfo('localhost') to be the IPv6 address instead of
the IPv4 address.

The change in the default 'localhost' address type causes
existing exports using '127.0.0.1' to fail, because the
'::1' address is tried first and fails. The problem is
not all the addresses in the address list are being tried.

So this patch allows that address list to continue to be
process when a 'EACCES' error is returned by the server.

Signed-off-by: Steve Dickson

mount.nfs4: Backgrounding mount broken with NFS versions <4

2012-10-15T19:31:23+00:00

When the NFS version isn't specified in the mount options, mount.nfs
attempts V4 first and appends 'vers=4' to the extra_options string in
the mount options.  If the server isn't immediately reachable, this
attempt fails.  However, if the background option is specified and the
server comes up later on, the extra_options are used again for all
further attempts and thus they fail if the server only supports
vers<4.

Fix this by only amending extra_options on a successful vers=4 mount.

This is now Debian bug #690181 and has apparently been around for
ages.

Reviewed-by: Chuck Lever 
Signed-off-by: Wolfram Gloger 
Signed-off-by: Steve Dickson

mount.nfs mapage: clear up confusion between 'proto' and 'transport'

2012-10-15T17:07:49+00:00

The mount option "proto=" actually set the "transport" which in
netconfig usage is the pairing of a protocol (e.g. UDP, TCP) with
a protocol family (e.g. INET, INET6).

This can cause confusion if people naively except "proto=udp" to work
equally well on IPv6.

So add some text to both nfs(5) and nfsmount.conf(5) to hopefully
clarify this.

Acked-by: Chuck Lever 
Signed-off-by: NeilBrown 
Signed-off-by: Steve Dickson

Added fsc and nofsc to the mount manpage.

2012-08-23T17:41:56+00:00

Signed-off-by: Steve Dickson

umount: use correct return value for is_vers4.

2012-08-06T13:11:27+00:00

is_vers4 in mount_libmount.c is based on nfs_umount_is_vers4
in nfsumount.c, except the return values are reversed.
The result of this is:
 - a MOUNT_UMNT call is not sent when an NFSv3 or NFSv2
   filesystem is unmounted
 - a MOUNT_UMNT call *is* sent when and 'nfs4' filesystem
   is unmounted (but not when an 'nfs -o vers=4 filesystem
   is unmounted, as that is checked elsewhere).

Signed-off-by: NeilBrown 
Signed-off-by: Steve Dickson

umount.nfs: ignore non-nfs filesystems

2012-08-01T15:14:21+00:00

 # umount.nfs /boot; echo $?
  umount.nfs: /boot: device is busy
  32

expected and fixed behavior:

 # umount.nfs /boot; echo $?
 # umount.nfs: /boot: is not an NFS filesystem
 1

Note that the function mnt_context_set_fstype_pattern() has never
been used for mtab/fstab evaluation. It's usable only for "umount -a"
and for "mount -t" operations.

Reported-by: NeilBrown 
Signed-off-by: Karel Zak 
Signed-off-by: Steve Dickson

mount.nfs: restore correct error status when umount fails

2012-07-16T12:53:32+00:00

If nfs-utils is built without --enable-libmount-mount, then
an unmount that failed due to the filesystem being busy will
exit with '16' - EX_FILEIO.
Autofs apparently relies on this.

When built with --enable-libmount-mount, the same case will
exit with '32' - EX_FAIL.  Normally this is reserved for
internal errors.

This patch restores the use of EX_FILEIO for errors from umount.

Reviewed-by: Karel Zak 
Signed-off-by: NeilBrown 
Signed-off-by: Steve Dickson

mount.nfs: try the next address after mount fails with ETIMEDOUT

2012-06-19T14:57:55+00:00

If a NFS mount attempt fails with an ETIMEDOUT error, the mount.nfs code
doesn't currently attempt the next address in the list. For a NFSv4
mount the initial mount() call almost always ends up going over
NFS_DEF_FG_TIMEOUT_MINUTES and the mount is never retried.

For a v3 mount, it ends up continually retrying against the same IPv6
address, and never tries the IPv4 address. Eventually it gives up once
it hits the NFS_DEF_FG_TIMEOUT_MINUTES timeout.

It's possible that a server is just unreachable via IPv6 (due to a
routing misconfiguration for instance), or is dropping IPv6 frames on
the floor. In that situation, it might still be reachable via IPv4 and
trying the next address could have allowed the mount to succeed.

Fix this by treating ETIMEDOUT in a similar fashion to ECONNREFUSED.
Have the client try the next address in the list before giving up and
returning an error.

Our QA folks noticed this after a routing problem in one of our test
labs. I was able to reproduce it by having the server drop incoming
IPv6 frames from the client's address.

With this patch, the mount eventually succeeds over IPv4 instead of
returning an error.

Cc: Chuck Lever 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve Dickson