summaryrefslogtreecommitdiffstats
path: root/utils/mount
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* nfs.man: add description of multiple sec= optionsWeston Andros Adamson2013-11-051-4/+13
| | | | | | | The client now supports multiple sec= options as a colon delimited list. Signed-off-by: Weston Andros Adamson <dros@netapp.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* statd: fix race condition for parallel startup of statdRobert Schiele2013-11-051-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | When start_statd figures out that statd is not yet running it starts it, waits for the invoked process to complete, and finally verifies that statd is working. This approach works for serially mounting NFS file systems but has a race condition for parallel mounting. In the parallel case it can happen that two mount commands A and B both decide that statd needs to be started. Both of them try to start statd. Obviously only one of them can successfully do so, let's assume this is command A in our case. The statd invoked by B terminates because the resource is already claimed by the statd invoked by A. The termination of B's statd though is before the statd of A has completely set up all things. This causes the check for a working statd of command B to fail and terminate the mount request with an error. To prevent this we define a timeout value. In case the initial check after invoking statd fails we try again in a loop 10 times a second until the timeout is reached. In our tests when the race occurred we typically were successful already on the first retry within the loop. Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: print an error message when remount attempt failsJeff Layton2013-10-211-0/+1
| | | | | | | | | Currently, mount.nfs returns an error code, but doesn't print anything when this occurs. Reported-by: Eric Doutreleau <edoutreleau@genoscope.cns.fr> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* nfsmount.conf: remove duplicate 'timeo' from the parsing stringSteve Dickson2013-10-211-0/+10
| | | | | | | | When the 'timeo' option is specified in multiple sections of the nfsmount.conf file, each instance is added to the parsing string. This patch make the first instance override any others. Signed-off-by: Steve Dickson <steved@redhat.com>
* nfsmount.conf: Remove duplicate 'bg' and 'fg' from parsing string.Steve Dickson2013-10-211-0/+25
| | | | | | | | | When the 'Background' and/or 'Foreground' options are set in multiple sections of the nfsmount.conf file, each instance gets added to the parsing string. This patch makes the first instance of either option override the any others. Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: improve handling of bg, fg, and sloppy in nfsmount.confScott Mayhew2013-08-191-0/+11
| | | | | | | | | | | | | | | | | | This patch makes 2 small improvements to the parsing of the bg, fg, and sloppy mount options in nfsmount.conf. 1. "bg" and "fg" negate should each other. "Background=True" should mean "bg" and "Background=False" should mean "fg". The same applies to "Foreground". 2. Once we see "Sloppy=False" while parsing the configuration file we should ignore subsequent occurrences of the sloppy option. This will preserve the "right-most setting wins" behavior for the sloppy mount option. Acked-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* mount.nfs: dont pass options from configuration sections that are not relevantScott Mayhew2013-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The nfsmount.conf file has the following format: [ section "arg" ] tag = value conf_get_tag_list() currently doesn't check the arg field so we wind up getting all the options that fall under a particular section value, instead of just the ones that match the specific "arg" field. As a result, we wind up passing options to the mount syscall from sections that aren't even relevant to the mount operation that is being performed. For example, if we have three different server sections, and each section has an Nfsvers tag, then the string we pass to the mount syscall will have two extra occurrences of the nfsvers option. Each option should appear at most 4 times -- once for the system section, once for the server-specific section, once for the mount-specific section, and once for the command line mount options. Acked-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* statd: exit if a statd is already runningWeston Andros Adamson2013-05-071-17/+0
| | | | | | | | Moves nfs_probe_statd from mount to nfs support lib to share with statd. 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-26 21:31:25 +0000