https://bugzilla.novell.com/show_bug.cgi?id=410802 User stvdo@gmx.net added comment https://bugzilla.novell.com/show_bug.cgi?id=410802#c392454 Summary: nfs-utils-1.1.2: possible bug: mount.nfs blocking when getting EACCES Product: openSUSE 11.0 Version: Final Platform: Other OS/Version: Linux Status: NEW Severity: Major Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: stvdo@gmx.net QAContact: qa@suse.de Found By: Customer Created an attachment (id=228994) --> (https://bugzilla.novell.com/attachment.cgi?id=228994) possible fix for nfs-utils-1.1.2 Hi, with the release of openSuse 11.0 I came in touch with nfs-utils version 1.1.2. After configuring a test system for automounting NFS exports from other machines, logins to the test machine began to take extremely long (about 2 minutes). I was able to track down the problem to blocking automount attempts to resources which where exported by the server, but to which the client test machine had no access permissions. I did an 'strace -p' on the blocking mount.nfs process and got the following: .. mount("rmnfs01:/gpfs/sw/TGSInventor/i386Linux", "/opt/TGSInventor", "nfs", MS_RDONLY|MS_NOSUID, "intr,addr=192.168.45.89") = -1 EACCES (Permission denied) time(NULL) = 1216380212 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({10, 0}, {10, 0}) = 0 mount("rmnfs01:/gpfs/sw/TGSInventor/i386Linux", "/opt/TGSInventor", "nfs", MS_RDONLY|MS_NOSUID, "intr,addr=192.168.45.89") = -1 EACCES (Permission denied) time(NULL) = 1216380222 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({10, 0}, {10, 0}) = 0 mount("rmnfs01:/gpfs/sw/TGSInventor/i386Linux", "/opt/TGSInventor", "nfs", MS_RDONLY|MS_NOSUID, "intr,addr=192.168.45.89") = -1 EACCES (Permission denied) .. The access to the NFS resource in question is restricted to certain machines, i.e. the client test machine is not allowed to mount it. The return value of EACCES of the mount system call is correct. But as of nfs-utils 1.1.1 this error qualifies as temporary in mount.nfs so that mount.nfs tries to mount the resource again and again! From utils/stropts.c: /* * Distinguish between permanent and temporary errors. * * Returns 0 if the passed-in error is temporary, thus the * mount system call should be retried; returns one if the * passed-in error is permanent, thus the mount system call * should not be retried. */ static int is_permanent_error(int error) { switch (error) { case EACCES: case ESTALE: case ETIMEDOUT: case ECONNREFUSED: return 0; /* temporary */ default: return 1; /* permanent */ } } In case of access restrictions the error should obviously not be considered temporary and the mount should fail straight away, so that it does not block subsequent operations. That's how nfs-utils <1.1.1 used to operate. After patching utils/stropts.c to not treat EACCES as temporary, the subsequent mounts worked as expected, i.e. returning immediately if access to the ressource was denied. Is this a bug, a conflict with other scenarios of EACCES? For our setup it is a bug and I have to patch stropts.c. I saw some discussion about the nfs client having to wait for rebooted servers which might lead to EACCES during the time window in which the server is not operational again. But I think mount.nfs should not be guessing about the state of the server and instead take an access error as a mount failure. Possible fix is attached. I tried to subscribe to the nfs-utils mailing list to discuss this behaviour and patch, but got no response. Bug is also referenced in #392454. Regards -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.