RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 883812 - autofs locks direct mount directory, but does not mount remote nfs share
Summary: autofs locks direct mount directory, but does not mount remote nfs share
Keywords:
Status: CLOSED DUPLICATE of bug 866271
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs
Version: 6.3
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-05 11:24 UTC by Thomas Schweikle
Modified: 2012-12-07 13:17 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-05 12:56:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Thomas Schweikle 2012-12-05 11:24:11 UTC 
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/
[...]
---

Looking at /proc/mounts:
---
/etc/auto.direct /X autofs rw,relatime,fd=6,pgrp=5293,timeout=300,minproto=5,maxproto=5,direct 0 0
---

Mounting the directory in question manualy after stopping autofs:
---
# /etc/init.d/autofs stop
Stopping automount:                                        [  OK  ]
# ll /X
total 8
drwxr-xr-x.  2 root root 4096 Dec  4 13:17 ./
dr-xr-xr-x. 26 root root 4096 Dec  4 13:17 ../
# mount -o rw,soft,intr,rsize=8192,wsize=8192 server:/somedir/somedir/dir /X
# ll /X
total 225656
drwxr-xr-x.  2 root root      4096 Dec  4 09:49 ./
dr-xr-xr-x. 26 root root      4096 Dec  4 13:17 ../
-rwxr-xr-x.  1 root root 231055405 Dec  4 08:17 eclipse-jee-juno-SR1-linux-gtk-x86_64.tar.gz*
# cat /proc/mounts
server:/somedir/somedir/dir /X nfs4 rw,relatime,vers=4,rsize=8192,wsize=8192,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.167.19.171,minorversion=0,local_lock=none,addr=192.192.192.192 0 0
---

Expected results:
autofs mounting /X as soon as someone cd into it

Additional info:
Works with Fedora 15,16
Does not work with Fedora 17,18; RedHat EL 6.3
Comment 2 Ian Kent 2012-12-05 12:55:31 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
Comment 3 Ian Kent 2012-12-05 12:56:10 UTC 

*** This bug has been marked as a duplicate of bug 866271 ***
Comment 4 Thomas Schweikle 2012-12-07 12:47:29 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.