summaryrefslogtreecommitdiffstats
path: root/utils/mount
Commit message (Collapse)AuthorAgeFilesLines
* mount.nfs: Use default minor version when -o v4 is specifiedSteve Dickson2017-06-211-10/+14
| | | | | | | When v4 is specified on the command line the default minor version needs to be used. Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: Use default minor version when -t nfs4 is specifiedSteve Dickson2017-06-211-3/+12
| | | | | | | When the nfs4 filesystem specified, the default major and minor versions should be used. Signed-off-by: Steve Dickson <steved@redhat.com>
* umount.nfs: assume path name is canonical.NeilBrown2017-06-131-0/+1
| | | | | | | | | | | | | | | | | | | | | /usr/bin/umount will always pass a canonical name to umount.nfs, so it is safe to disable canonicalization. When umounting an NFS filesystem, it is generally safest to not "stat" the mountpoint at all as that can block indefinitely. umount() will not block, but lstat() etc can. By disabling canonicalization in libmount, we discourage it from ever calling 'stat' family operations, and thus reduce the chance of a hang. Note that to be fully effective, this requires changes to util-linux which have not yet been accepted. When both that change and this are in effect, automounters can use "umount -c $PATH" to safely unmount a filesystem without blocking. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: improve version negotiation when vers=4 is specified.NeilBrown2017-06-011-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | If NFSv4, in general, is requested (possibly by -t nfs4 or -o v4 or -o vers=4 etc) then we need to negotiate the best minor version, but must not fallback to v3 or v2. Internally, this state is reflected in v_mode == V_GENERAL. This means that a major version was given, but the minor version still needs to be negotiated. This is handled by nfs_autonegotiate(). It currently does the right thing for EPROTONOSUPPORT and EINVAL, but not for other errors. In particular, ENOENT can cause problems as NFSv4 might export a different namespace than NFSv3 (e.g. by using fsid=0 in the Linux NFS server). Currently a mount request for NFSv4 and a particular path can result if an NFSv3 mount if the path is available with v3 but not v4. So move the special handling of V_GENERAL into the common fall_back: code, and add extra checking in the ENCONNREFUSED case, which does not use fall_back:. Tested-by: Steve Dickson <steved@redhat.com> Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: Restore errno after v3 mounts on ECONNREFUSED errorsSteve Dickson2017-05-051-1/+4
| | | | | | | | | | | | Commit 65ac59cd introduced code that tries v3 mounts when the the v4 mount fails with ECONNREFUSED. This code allows failing back to v3 to work correctly. When the v3 mount fails the original errno value has been over rewritten. In these case the errno value needs to be restored to ECONNREFUSED. Signed-off-by: Steve Dickson <steved@redhat.com>
* config: Remove the conf_path globalJustin Mitchell2017-05-052-5/+5
| | | | | | | | Working towards an nfs.conf library and API for system config tools, first step, replace the conf_path global with a parameter to conf_init Signed-off-by: Justin Mitchell <jumitche@rehat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: call setgroups() before setuid()NeilBrown2017-02-151-0/+2
| | | | | | | | | | | | | | | It is generally wise to call setgroups() (and setgid()) before calling setuid() to ensure no unexpected permission leaks happen. SUSE's build system checks all binaries for conformance with this and generates a warning for mountd. As we are setting the uid to 0, there is no risk that the group list will provide extra permissions, so there is no real risk here. But it is nice to silence warnings, and including a setgroups() call is probably a good practice to encourage. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: fix mount fail that caused by uninitialized structJianhong Yin2017-02-022-0/+5
| | | | | | | | | | | | | From: "Jianhong.Yin" <yin-jianhong@163.com> recent changes of utils/mount cause a regression mount fail: https://bugzilla.redhat.com/show_bug.cgi?id=1415024 can not reproduce it on x86_64(gcc on x86_64 might do struct initialize by default, I'm not sure). but it can be reproduced always on platform ppc64le aarch64. Signed-off-by: Jianhong Yin <yin-jianhong@163.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: take history into account when assessing if an error is permanent.NeilBrown2016-12-061-5/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When attempting an NFSv3 mount request, it is possible to catch the server at an "awkward" moment while it is still starting up. In these cases it is possible to get an error that would otherwise indiciate a permanent error, but which should be considered temporary during the start-up window. In particular: ECONNREFUSED will be returned between the time the network interface is configured, and the time that rpcbind starts EOPNOTSUPP (representing RPC_PROGNOTREGISTERED) will be returned between the time that rpcbind starts and the time when nfsd registers, and ESTALE will be returned between the time nfsd starts and when filesystems are exported (this windown can be removed with correct configuration). So these errors only deserve a relatively small timeout. ECONNREFUSED needs a longer timeout than the others as the start-up window is longer. As we have long treated this as a temporary error, with no complaints, we will keep doing so for now. So change nfs_is_permanent_error() to record the previous error and the number of times the same error has been seen. If ESTALE or EOPNOTSUPP is seen 3 times (over 3 seconds or more) or ECONNREFUSED is seen 5 times (15 seconds), report a permanent error, others assume it could be temporary. A result of this is that if you try a UDP mount from a server which doesn't support UDP, you get an error without a few seconds, rather than a 2-minute timeout. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: don't hide temporary error code on timeout.NeilBrown2016-12-061-3/+1
| | | | | | | | | | | | If a mount attempt times out due to repeated non-permanent errors, we always report ETIMEDOUT rather than the actual error. Errors like "ECONNREFUSED" or "EHOSTUNREACH" or "ESTALE" might be more useful than the generic "ETIMEDOUT". So preserve the error code. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: RPC_PROGNOTREGISTERED should not be a permanent errorNeilBrown2016-08-221-4/+3
| | | | | | | | | | | | | | | | | | | | | | Commit: bf66c9facb8e ("mounts.nfs: v2 and v3 background mounts should retry when server is down.") changed the behaviour of "bg" mounts so that RPC_PROGNOTREGISTERED, which maps to EOPNOTSUPP, is not a permanent error. This useful because when an NFS server starts up there is a small window between the moment that rpcbind (or portmap) starts responding to lookup requests, and the moment when nfsd registers with rpcbind. During that window rpcbind will reply with RPC_PROGNOTREGISTERED, but mount should not give up. This same reasoning applies to foreground mounts. They don't wait for as long, but could still hit the window and fail prematurely. So revert the above patch and instead add EOPNOTSUPP to the list of temporary errors known to nfs_is_permanent_error. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: use a public address for IPv6 callback.NeilBrown2016-08-031-0/+5
| | | | | | | | | | | | If IPv6 address privacy is active, the "clientaddr" given to the server will likely be a temporary address which will eventually expire, thus breaking callback. So ask for a public address to ensure continued service. Acked-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: don't treat temporary name resolution failure as permanentNeilBrown2016-08-031-23/+31
| | | | | | | | | | | | | | | | | | If getaddrinfo() returns EAI_AGAIN, we shouldn't just give up, but should continue normal retries as the nameserver may be unavailable for the same reason as the NFS server. So move the getaddrinfo() call from nfs_validate_options() into nfs_try_mount() which is always called soon after, except in the 'remount' case when we don't want it anyway. If EAI_AGAIN is returned, set errno to EAGAIN and allow this to be a temporary failure. Otherwise report error and set errno to EALREADY so no further message is given. Acked-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* nfs.man: clarify effect of 'retry' optionNeilBrown2016-08-031-2/+12
| | | | | | | | | | | | | | | | | | | | | The total timeout for a "mount" attempt to a non-responsive server will always be a multiple of the time a single mount attempt in the kernel takes, which for TCP defaults to about 4 minutes. The documentation for the "retry" option seems to suggest that this can be used to set a maximum but it really sets a time after which to stop retrying. The total can be as much as "retry" plus the time for a single attempt. So clarify the documentation a bit, and also note that retrans defaults are different for UDP and TCP: #define NFS_DEF_UDP_RETRANS (3) #define NFS_DEF_TCP_RETRANS (2) Reported-by: Howard Guo<hguo@suse.com> Acked-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* nfs(5): Add lease management security considerationsChuck Lever2016-07-181-3/+56
| | | | | | | | | | | | | | | | | | | | Several years ago, the kernel Linux NFS client was changed to attempt to use strong security for lease management operations that are shared by all NFSv4 mounts of a server on that client. This forces the client to use a consistent security flavor and principal for lease management, even across reboots, to ensure that state recovery works, independent of what mounts have been done, what order they were done, and with what sec= option. The use of krb5i for lease management does not affect the flavor used for RPCs done on behalf of individual users, but sometimes it means krb5i is used for certain operations even when "sec=sys" is specified. This has occasionally been surprising. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1334510 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* umount: fixed typo in usage messageSteve Dickson2016-06-071-1/+1
| | | | Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: added usage output when no arguemnts are givenSteve Dickson2016-06-071-0/+2
| | | | Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: run START_STATD fully as rootNeilBrown2016-04-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | If a "user" mount is the first NFSv3 mount, mount.nfs will be running setuid to root (with non-root as the real-uid) when it executes START_STATD. start-statd is a shell script and many shells refuse to run setuid, dropping privileges immediately. This results in start-statd running as an unprivileged user and so statd fails to start. To fix this, call "setuid(0)" to set real uid to zero. Also call "setgid(0)" for consistency. The behaviour of a shell can often be affected by the environment, such as the "shell functions" that bash includes from the environment. To avoid the user being able to pass such environment to the shell, explicitly pass an empty environment. The start-statd script explicitly sets the PATH which is all it really needs. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: skip server address resolution on remountBenjamin Coddington2016-04-271-11/+20
| | | | | | | | | | | | A remount might fail if name resolution returns a different server address, as might occur if there are multiple name records for the server. Since we cannot change the server's address on a remount anyway, skip the lookup and remove any set addresses in the options. Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs - hide EBUSY errorsNeilBrown2016-03-161-0/+9
| | | | | | | | | | | | | | | | | | | | Linux only returns EBUSY for a non-remount mount if the exact requested filesystem is already mounted. Arguably this is not an error. "mount -a" tries to see if each requested filesystem is already mounted. Sometimes it gets it wrong - e.g. hostname aliases can confuse it. So "mount -a" will report a failure "already mounted", which is wrong because it should filter those out. An easy fix it just to be silent about EBUSY. As the requested result (a given filesystem being mounted at a given location) is in effect after the EBUSY return, we can just treat it as success. This removes the confusing "already mounted" errors. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: trust the exit status of "start_statd".NeilBrown2016-01-161-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If DNS service is particularly slow, nfs_probe_statd() can fail even though rpc.statd is actually running. This happens because rpc.statd is single threaded and could be waiting longer for DNS than nfs_probe_statd() will wait for it. This causes problems when mount.nfs uses nfs_probe_statd() to see if statd is running, as is needed for NFSv3. Currently in these circumstances there are two possible outcomes. 1/ if systemd is in use, it will be told to start rpc-statd, which is already running so no change. mount.nfs will try pinging rpc.statd a few more times and could eventually give up and fail the mount. While slow DNS may well result in slow service, it shouldn't cause a mount attempt to fail. 2/ if systemd is not in use, a new rpc.statd will be started. This can (and has) lead to a large number of rpc.statd processes running on the one machine. This patch addresses the first scenario. If START_STATD is run and exits with a success status, mount.nfs assumes statd is running and allows the mount to succeed. A separate patch will address the other scenario. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* Fix protocol minor version fall-backTakashi Iwai2016-01-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | mount.nfs currently expects mount(2) to fail with EPROTONOSUPPORT if the kernel doesn't understand the requested NFS version. Unfortunately if the requested minor is not known to the kernel it returns -EINVAL. In kernels since 3.11 this can happen in nfs4_alloc_client(), if compiled without NFS_V4_2. More generally it can happen in in nfs_validate_text_mount_data() when nfs_parse_mount_options() returns 0 because nfs_parse_version_string() didn't recognise the version. EPROTONOSUPPORT is only returned if NFSv4 support is completely compiled out. So nfs_autonegotiate needs to check for EINVAL as well as EPROTONOSUPPORT. URL: https://bugzilla.opensuse.org/show_bug.cgi?id=959211 Reported-by: Takashi Iwai <tiwai@suse.com> Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* Fix uninitialised variable usage in nfs_options2pmapAndreas Schwab2016-01-161-1/+4
| | | | | | | | | | | | | | | | | | Commit 5bea22e33b7a introduced a regression. Prior to that commit nfs_nfs_version would set *version to 0 if NFS version wasn't specified. Since that commit, version.v_mode is set to V_DEFAULT if the NFS version isn't specified, but nfs_options2pmap uses version.major without checking v_mode. This can lead to incorrect behaviour. In particular fall-ack to v3 if server doesn't support v4 can fail. So test v_mode before using version.major. URL: https://bugzilla.opensuse.org/show_bug.cgi?id=956743 Fixes: 5bea22e33b7a ("mount.nfs: Add struct nfs_version and generalize version parsing") Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: fix null pointer derefernce in nfs_parse_simple_hostnameVivek Trivedi2015-12-111-1/+2
| | | | | | | | | In function nfs_parse_simple_hostname, hostname can be NULL, dereferncing it while passing it to free(*hostname) may result in segfault. Signed-off-by: Vivek Trivedi <t.vivek@samsung.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: Teach mount.nfs about the mountversion optionSteve Dickson2015-11-211-1/+6
| | | | | | | | | | When the mountversion option is used, there should not be any mount negotiations with the server. Also, when the option is used, its know that the mount is a v4 mount and a V_SPECFIC type. Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs manpage: Add nfsmount.confSteve Dickson2015-06-251-1/+4
| | | | | | | Add nfsmount.conf to both the FILES and SEE ALSO sections Signed-off-by: Steve Dickson <steved@redhat.com>
* nfs manpage: Add nfsmount.confSteve Dickson2015-06-251-0/+4
| | | | | | | Add nfsmount.conf to both the FILES and SEE ALSO sections Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: Writes signal number to kernel as command lineKinglong Mee2015-05-061-2/+7
| | | | | | | | | | | | When mounting nfs with -overs=4,minorversion=2, want getting nfs mounts with vers=4.2, but got vers=4.0 as, It's caused by mount.nfs writing bad vers to kernel. This patch lets mount.nfs writing signal number to kernel as command line. Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* When mounting nfs with -ov4, -overs=4 or -onfsvers=4, fail as,Kinglong Mee2015-05-061-9/+3
| | | | | | | | | | | mount -t nfs -ov4 192.168.31.12:/ /testidr/ mount.nfs: access denied by server while mounting 192.168.31.12:/ Fixes: f980298853 "mount.nfs: configurable minor version defaults" Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs.man, nfs.man: Update distinction between fstypesBen Hutchings2015-04-021-4/+8
| | | | | | | | | | From: Ben Hutchings <ben@decadent.org.uk> this is a resync of the man page updates in the Debian package with mainline nfs-utils. Acked-By: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: improve error message when statd cannot be started.NeilBrown2015-03-262-0/+4
| | | | | | | | | | | | | | | | | | | | | | If you try to mount and NFSv3 filesystem, and statd is not running and cannot be started (maybe rpcbind isn't running either), the error message is: mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. mount.nfs: an incorrect mount option was specified That last line is incorrect and misleading: no incorret mount option was specified. This line comes from mount_error() in error.c. In this case that function doesn't really need to provide any more information. So introduce a concention that EALREADY means an error message has already been printed, and use it to suppress that message. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: configurable minor version defaultsBenjamin Coddington2015-01-231-43/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update nfsmount.conf to allow minor version specification, and rearrange the autonegotiation logic to agreed upon best behavior. Depending upon the combination of values specified within nfsmount.conf and given to mount.nfs, the retry behavior of mount.nfs varies according to the general rule of defaulting to the most specific setting, with some exceptions. A general guide to the expected behavior follows: ------------------ | nfsmount.conf |----------------------------------- | Defaultvers= | arg option | attempts: | |---------------------------------------------------| | 4.2 | not set | v4.2 v4.1 v4.0 v3 | | 4.2 | v4 | v4.2 v4.1 v4.0 | | 4.1 | not set | v4.1 v4.0 v3 | | 4.1 | v4 | v4.1 v4.0 | | 4 | not set | v4.0 v3 | | 4 | v4 | v4.0 | | 3 | not set | v3 | | any set | v4.2 | v4.2 | | any set | v4.1 | v4.1 | | any set | v4 | v4.0 | | any set | v3 | v3 | | not set | not set | v4.2 v4.1 v4.0 v3 | ----------------------------------------------------- If built with --enable-mountconfig=no, then the behavior is the same as if nfsmount.conf did not set Defaultvers. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* nfsmount.conf: Always parse versionsBenjamin Coddington2015-01-231-34/+0
| | | | | | | | | | | In order to make decisions about which default version to use when only the major version is specified, the nfsmount.conf Defaultvers options should always be parsed, even when a version has already been specified. Remove the check and bypass for parsing the Defaultvers options from nfsmount.conf. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: Add struct nfs_version and generalize version parsingBenjamin Coddington2015-01-235-77/+88
| | | | | | | | | | | | | | | | | | The nfs_version needs to carry major, minor, and basic mode information to allow decisions to be made to override, discard, or negotiate various versions. Update nfs_nfs_version() to work against this struct and set the various modes. This change also makes nfs_nfs_version() parse properly for future version number additions. The general rules for version.v_mode are - not set V_DEFAULT - single digit => 4 V_GENERAL - single digit < 4 V_SPECIFIC - decimal included V_SPECIFIC - miss all others V_PARSE_ERR Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: parse options - add helper po_contains_prefixBenjamin Coddington2015-01-232-0/+26
| | | | | | | | | | The version options (v3,v4,v4.2) may increase in the future, but they have a predictable prefix. Add a parse option helper to locate and return these options by prefix so that a future increment of version does not require the addition of strings to a search table. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: fix a comment typo in parse optionsBenjamin Coddington2015-01-231-1/+1
| | | | | Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* Fix up issue with "make dist"NeilBrown2014-12-071-4/+6
| | | | | | | | | | | | | Add mention of new files, remove mention of old files, and cause "make dist" to create something very similar to the current distributions. systemd files are not currently included in "make dist" and some files generated by "rpcgen" are (though they aren't in official distribution). Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
* umount: make it sensitive to -vKarel Zak2014-10-241-1/+13
| | | | | | | Let's print verbose messages like original non-libmount version. Signed-off-by: Karel Zak <kzak@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* Include libgen.h for basenameNatanael Copa2014-09-152-0/+2
| | | | | | | | | | According POSIX basename(3) should have an #include <libgen.h> There are a different GNU implementation too, that can be used with _GNU_SOURCE, but the POSIX version is good enough and more portable. Signed-off-by: Natanael Copa <ncopa@alpinelinux.org> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: print more useful error messageKinglong Mee2014-06-011-2/+6
| | | | | | | | | | | | | | | | When mounting spec of a regular file, mount.nfs print error message as, mount.nfs: mount point /mnt is not a directory mount.nfs: mount point /mnt/testfile is not a directory This patch lets mount.nfs print more useful message, mount.nfs: mount spec 127.0.0.1:/root/testfile or point /mnt is not a directory mount.nfs: mount point /mnt/testfile is not a directory Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* Added more (commented out) options to nfsmount.confSteve Dickson2014-04-291-0/+9
| | | | Signed-off-by: Steve Dickson <steved@redhat.com>
* mount: chk_mountpoint should only check for execute perms for unpriveleged usersScott Mayhew2014-03-221-1/+1
| | | | | | | | Otherwise 'mount -o remount' fails on mounts that have root squashing enabled and world execute perms disabled. Signed-off-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* nfs(5): intr/nointr are ignored nowJim Rees2014-03-131-47/+4
| | | | | Signed-off-by: Jim Rees <rees@umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com>
* [PATCH - v3] mount.nfs: Fix fallback from tcp to udpNeilBrown2014-03-133-18/+50
| | | | | | | | | | | | | | | | | | | | | | | | | Protocol negotiation in mount.nfs does not correctly negotiate with a server which only supports NFSv3 and UDP. When mount.nfs attempts an NFSv4 mount and fails with ECONNREFUSED it does not fall back to NFSv3, as this is not recognised as a "does not support NFSv4" error. However ECONNREFUSED is a clear indication that the server doesn't support TCP, and ipso facto does not support NFSv4. So ECONNREFUSED should trigger a fallback from v4 to v2/3. However ECONNREFUSED may simply indicate that NFSv4 isn't supported *yet*. i.e. the server is still booting and isn't responding to NFS requests yet. So if we subsequently find that NFSv3 is supported, we need to check with the server to confirm that NFSv4 really isn't supported. If server reports that v4 is not supported after reporting that v3 is, we can safely use v4. If it reports that v4 is supported, we need to retry v4. Signed-off-by: Steve Dickson <steved@redhat.com> Reported-by: Carsten Ziepke <kieltux@gmail.com>
* mount.nfs: Removed supported flag from usage stringSteve Dickson2014-01-201-1/+1
| | | | Signed-off-by: Steve Dickson <steved@redhat.com>
* nfs(5): Clarify DATA AND METADATA COHERENCE sectionChuck Lever2014-01-201-10/+27
| | | | | Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: Don't silently ignore invalid protocol versions.Steve Dickson2014-01-071-0/+4
| | | | Signed-off-by: Steve Dickson <steved@redhat.com>
* nfs(5): Treatment of *atime mount optionsChuck Lever2013-11-201-0/+59
| | | | | | | | | | | | | I was reminded recently that NFS treats file atime time stamps differently than other filesystems. It also ignores the generic *atime mount options because it cannot support the atime semantics of local filesystems. We should document that somewhere. nfs(5) seems like a logical place for it. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* nfs(5): Document the "migration" mount optionChuck Lever2013-11-201-0/+20
| | | | | | | Support for NFSv4 migration was merged in 3.13. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: Recognize v4.x mount optionsWeston Andros Adamson2013-11-201-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel understands text options of the form "v4.x" (ie "v4.1"), but mount.nfs does not and this leads to weird errors when the requested mount fails: a line in dmesg about version 3 not supporting minorversions and mount.nfs returning EINVAL no matter what the real error was. This happens because mount.nfs thinks no version was specified so it starts probing other versions which conflicts with the v4.X option once it gets parsed by the kernel. $ sudo mount -v -o v4.1 zero:/invalid_export /mnt mount.nfs: timeout set for Wed Nov 13 10:09:48 2013 mount.nfs: trying text-based options 'v4.1,vers=4,addr=192.168.100.10,clientaddr=192.168.100.11' mount.nfs: mount(2): No such file or directory mount.nfs: trying text-based options 'v4.1,addr=192.168.100.10' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048 mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified And you get this in dmesg: NFS: mount option vers=3 does not support minorversion=1 but if you use another form of the same options, this doesn't happen: $ sudo mount -v -o vers=4,minorversion=1 zero:/invalid_export /mnt mount.nfs: timeout set for Wed Nov 13 10:10:28 2013 mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.100.10,clientaddr=192.168.100.11' mount.nfs: mount(2): No such file or directory mount.nfs: mounting zero:/invalid_export failed, reason given by server: No such file or directory Acked-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Weston Andros Adamson <dros@netapp.com> Signed-off-by: Steve Dickson <steved@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-27 20:39:19 +0000