mount: No longer negotiate to v2 This patch remove the ability of negotiating to the v2 protocol. Explicitly setting the version on the command line will be the only way to use v2. Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Continue to trying address when the server return EACCES 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 <steved@redhat.com>
mount.nfs4: Backgrounding mount broken with NFS versions <4 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 <chuck.lever@oracle.com> Signed-off-by: Wolfram Gloger <bugzilla1@malloc.de> Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: try the next address after mount fails with ETIMEDOUT 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 <chuck.lever@oracle.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
mounts.nfs: v2 and v3 background mounts should retry when server is down. The point of background mounts is to have the mount retried if the mount fails. This patch allows the v2/v3 background mount to proceed in the case when the server is down by not making EOPNOTSUPP a permanent error. Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Background mounts failing on time out errors. Mounting with the "-o v3,bg,proto=udp" options will fail, instead of retrying, when the server is down. The reason being nfs_rewrite_pmap_mount_options() does not interrupt RPC timeouts correctly. Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Mount should really return from errno test We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2. Before, only a break in swich can not make the program out of for loop. Signed-off-by: Yang Bai <hamo.by@gmail.com> Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Preserve any explicit port=2049 option If NFS port (2049) is supplied explicitly, don't ignore this setting by requesting it to portmapper again. Signed-off-by: Luk Claes <luk@debian.org> Signed-off-by: Steve Dickson <steved@redhat.com>
pdate addres for Free Software Foundation License texts contain multiple address for FSF, some wrong. So update them and replace COPYING file with http://www.gnu.org/licenses/gpl-2.0.txt which has a few changes to preamble and commentary. Also remove extra COPYING file from utils/statd/ Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: submarvellous messages from mount.nfs Consider a setup where mountd on the server is controlled via tcp_wrappers (usual RHEL setup) and will not process calls from a particular client because of something in /etc/hosts.deny. When such client attempts to do v3 mount, the error message printed by mount.nfs is misleading. This patch changes that error message from: mount.nfs: Argument list too long to mount.nfs: access denied by server while mounting server:/export Signed-off-by: Steve Dickson <steved@redhat.com>
mount: Remove MOUNT_CONFIG warnings The following changes are needed to remove compile warnings when MOUNT_CONFIG is not defined Signed-off-by: Steve Dickson <steved@redhat.com>
Removed a couple warnings from utils/mount/stropts.c stropts.c:740:6: warning: 'ret' may be used uninitialized in this function stropts.c:653:6: warning: 'ret' may be used uninitialized in this function Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Fix memory leak in nfs_sys_mount() This appears to have been left behind by last year's adjustments to how the extra_opts string is constructed. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
mount: Fix compiler warning in nfs_parse_retry_option() stropts.c: In function nfs_parse_retry_option: stropts.c:131: warning: conversion to unsigned int from long int may alter its value Make it more clear what the second argument is for, and flag the switch fallthrough case. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
nfs-utils: Remove all uses of AI_ADDRCONFIG It was reported that, if only "lo" is up, mount.nfs 127.0.0.1:/export /mount fails with "Name or service not known". "man 3 getaddrinfo" says this: If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses are returned in the list pointed to by res only if the local system has at least one IPv4 address configured, and IPv6 addresses are only returned if the local system has at least one IPv6 address configured. The man page oversimplifies here. A review of glibc shows that getaddrinfo(3) explicitly ignores loopback addresses when deciding whether an IPv4 or IPv6 address is configured. This behavior around loopback is a problem not just for mount.nfs, but also for RPC daemons that have to start up before a system's networking is fully configured and started. Given the history of other problems with AI_ADDRCONFIG and the unpredictable behavior it introduces, let's just remove it everywhere in nfs-utils. This fix addresses: https://bugzilla.linux-nfs.org/show_bug.cgi?id=191 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Don't do anything fancy if this is a remount We don't want to append "vers=4" or perform any negotiation if the "remount" mount option was specified. It will just end in tears. This attempts to address https://qa.mandriva.com/show_bug.cgi?id=60311 and https://bugzilla.linux-nfs.org/show_bug.cgi?id=187 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Refactor mount version and protocol autonegotiation Clean up. I'm beginning to agree with Bruce and Steve's assessment that the fallthrough switch case in nfs_try_mount() is more difficult to read and understand than it needs to be. The logic that manages negotiating NFS version and protocol settings is getting more complex over time anyway. So let's split the autonegotiation piece out of nfs_try_mount(). We can reduce indenting, and use cleaner switch-based logic. Also, adding more comments can only help. Neil also suggested replacing the pre-call "errno = 0" trick. The lower-level functions may try to mount several times (given a list of addresses to try). errno could be set by any of those. The mount request will succeed at some point, and "success" is returned, but errno is still set to some non-zero value. The kernel version check in nfs_try_mount() is more or less loop invariant: it's impossible for the result of that test to change between retries. So we should be able to safely move it to the logic that sets the initial value of mi->version. This patch is not supposed to cause a behavioral change. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Cleaned up a warning from commit 44f09b7 Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Prepare way for "vers=4,rdma" mounts At some point, when the kernel starts to support "vers=4,rdma" mounts, we will want the mount.nfs command to pass "vers=4,rdma" mounts instead of rejecting them. Assuming that the kernel will reject these today with EPROTONOSUPPORT, that would cause the version fallback logic to go to "vers=3,rdma" automatically. So the extra check we have now is not needed anyway. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
mount.nfs: Use nfs_nfs_protocol() for checking for proto=rdma Clean up: Now that nfs_get_proto() can recognize "rdma" we can re-use nfs_nfs_protocol() instead of ad hoc checks for "proto=rdma". Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>