Bug 883812
Summary: | autofs locks direct mount directory, but does not mount remote nfs share | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Thomas Schweikle <tschweikle> |
Component: | autofs | Assignee: | Ian Kent <ikent> |
Status: | CLOSED DUPLICATE | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.3 | CC: | ikent, nfs-maint |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-12-05 12:56:10 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Thomas Schweikle
2012-12-05 11:24:11 UTC
(In reply to comment #0) > Description of problem: > after configuring autofs with: > - /etc/auto.master: > --- > /- /etc/auto.direct > --- > > - /etc/auto.direct: > --- > /X -rw,soft,intr,rsize=8192,wsize=8192 server:/somedir/somedir/dir > --- > > Version-Release number of selected component (if applicable): > autofs-5.0.5-55.el6_3.x86_64 > > How reproducible: > always > > Steps to Reproduce: > 1. Install Server install autofs, nfs-common > 2. configure autofs > 3. start autofs > > Actual results: > directory /X is locked, trying to cd into it doesn't mount anything, but > gives back an error: > --- > # /etc/init.d/autofs start > Starting automount: [ OK ] > # ll X > ls: cannot open directory X: No such file or directory > # ll / > ls: cannot access X: No such file or directory > total 120 > dr-xr-xr-x. 26 root root 4096 Dec 4 13:17 ./ > dr-xr-xr-x. 26 root root 4096 Dec 4 13:17 ../ > -rw-r--r--. 1 root root 0 Dec 4 08:33 .autofsck > drwx------. 3 root root 4096 Oct 31 16:38 .dbus/ > d?????????? ? ? ? ? ? X/ > dr-xr-xr-x. 2 root root 4096 Nov 7 03:16 bin/ > [...] > --- This appears to be a duplicate of bug 866271, certainly I can reproduce it using an early 6.3 kernel and verified it is not a problem using kernel kernel-2.6.32-338.el6. snip ... > > Additional info: > Works with Fedora 15,16 > Does not work with Fedora 17,18; RedHat EL 6.3 The fix for the problem in bug 866271 has been sent upstream and is present in recent Fedora kernels, certainly on F17 with 3.6.6-1 the change is present and I cannot duplicate the problem. You may however not be seeing the same bug on Fedora. Ian *** This bug has been marked as a duplicate of bug 866271 *** I've had a really close look at internal data found at Fedora 17,18 and RedHat EL 6.3. Same problem. This has an other side effect: create an export: /data/share/home *.somedomain.example(rw,sync,no_root_squash,no_all_squash) mount it on two different servers: clt1# mount srv:/data/share/home /home clt2# mount srv:/data/share/home /home on clt1: drwxr-xr-x. 109 root root 12288 7. Dez 13:14 etc drwxr-xr-x. 2 root root 4096 3. Dez 15:22 home dr-xr-xr-x. 11 root root 4096 12. Okt 17:19 lib on clt2: drwxr-xr-x. 115 root root 12288 7. Dez 13:25 etc drwxrwxrwx 7 nobody nobody 4096 7. Dez 11:15 home dr-xr-xr-x. 11 root root 4096 6. Nov 08:22 lib On clt2 *all* is mapped to nobody:nobody, as if "all_squash" had been given in exports. Maybe this is an additional error with this particular kernel. I'm trying to down/upgrade the kernel to the most recent one now, because nfs seems seriously broken with this one on RedHat EL 6.3 "uname -a" gives back on all three systems: Linux srv 2.6.39-300.17.2.el6uek.x86_64 #1 SMP Wed Nov 7 17:48:36 PST 2012 x86_64 x86_64 x86_64 GNU/Linux |