Bug 771092

Summary: Problem with autofs mounting with mount points on the same computer
Product: Red Hat Enterprise Linux 6 Reporter: Amir Hedayaty <hedayaty>
Component: autofsAssignee: Ian Kent <ikent>
Status: CLOSED NOTABUG QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.2CC: ikent
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-01-05 08:39:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
autofs Log none

Description Amir Hedayaty 2012-01-01 08:16:55 UTC 
Here is the situation:

I have a maintaining computers for our research lab, almost every computer is assigned to specific person; however, sometimes there is a need to share the computers.

So we have NIS server for user info, and kerberos for authentication (kerbesoe is not important here), the home of each user is on his own computer (this is required since we are using huge huge datasets) also exported via nfs.

The location of homes are exported through NIS auto.home map.
If the user seats on his own computer, autofs mounts his home folder with bind option (not nfs), and if user logins to another computer it uses nfs.

The system worked fine, until the upgrading one the computer to version 6 and autofs-5.0.5-39.el6.x86_64

The problem is that, in the case the mount point is on the same computer it can not mount is any more. The users on that computer are able to use other computers, also other users are able to use that computer.

The hostname is "toros", the original location of files are at "toros:/data/fhach", it tries to mount /home/fhach. Here is the autofs log


Dec 29 21:49:24 toros automount[2433]: sun_mount: parse(sun): mounting root /home, mountpoint fhach, what toros:/data/fhach, fstype nfs4, options
Dec 29 21:49:24 toros automount[2433]: mount_mount: mount(nfs): root=/home name=fhach what=toros:/data/fhach, fstype=nfs4, options=
Dec 29 21:49:24 toros automount[2433]: mount_mount: mount(nfs): nfs options="", nosymlink=0, ro=0
Comment 2 Ian Kent 2012-01-03 00:09:19 UTC 
(In reply to comment #0)
> 
> The problem is that, in the case the mount point is on the same computer it can
> not mount is any more. The users on that computer are able to use other
> computers, also other users are able to use that computer.

Could it be that the server has been updated as well, perhaps to
use the virtual root feature of NFSv4? In that case the export
path and the mount path are no longer the same.

> 
> The hostname is "toros", the original location of files are at
> "toros:/data/fhach", it tries to mount /home/fhach. Here is the autofs log
> 
> 
> Dec 29 21:49:24 toros automount[2433]: sun_mount: parse(sun): mounting root
> /home, mountpoint fhach, what toros:/data/fhach, fstype nfs4, options
> Dec 29 21:49:24 toros automount[2433]: mount_mount: mount(nfs): root=/home
> name=fhach what=toros:/data/fhach, fstype=nfs4, options=
> Dec 29 21:49:24 toros automount[2433]: mount_mount: mount(nfs): nfs options="",
> nosymlink=0, ro=0

Can you provide the whole debug log, from autofs start to problem
occurrence please.

Ian
Comment 3 Amir Hedayaty 2012-01-04 04:35:21 UTC 
Created attachment 550594 [details]
autofs Log
Comment 4 Amir Hedayaty 2012-01-04 04:40:09 UTC 
Only this client has been updated, the server is still running version 5

As I mentioned everything else works fine, except the case bind mount is needed.

I have attached a log, hope it is fine, I added "-d" to the options and filtered message log by pid.
Comment 5 Amir Hedayaty 2012-01-04 04:48:59 UTC 
I just solved the issue, there is a record in /etc/hosts mapping hostname to local ipv6 address, removing that line fixed. 

I guess the bug can be closed
Comment 6 Ian Kent 2012-01-05 08:39:03 UTC 
(In reply to comment #5)
> I just solved the issue, there is a record in /etc/hosts mapping hostname to
> local ipv6 address, removing that line fixed. 
> 
> I guess the bug can be closed

Ha, ok.

After looking at the log I was puzzled as to why it wasn't
working but then I saw this comment.

Ian