Bug 209638 - mount of /net mountpoint failed due to exports lookup failure
mount of /net mountpoint failed due to exports lookup failure
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-06 11:43 EDT by Clark Williams
Modified: 2013-12-23 20:53 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-15 18:28:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
syslog output of 'automount --debug' (10.09 KB, text/plain)
2006-10-06 12:45 EDT, Clark Williams
no flags Details
Make masked_match independent of hostname for exports comparison. (3.76 KB, patch)
2006-10-07 05:10 EDT, Ian Kent
no flags Details | Diff

  None (edit)
Description Clark Williams 2006-10-06 11:43:00 EDT
Description of problem:

attempting to access a filesystem via the /net mechanism fails 

Version-Release number of selected component (if applicable):

autofs-5.0.1-0.rc2.8
nfs-utils-1.0.9-8.fc6
kernel-2.6.18-1.2741.fc6

How reproducible:
Always

Steps to Reproduce:
1. boot system
2. type "ls /net/<known system>/mountpoint

  
Actual results:
[williams@riff ~]$ ls /net/toaster/vol
ls: /net/toaster/vol: No such file or directory


Expected results:
[williams@riff ~]$ ls /net/toaster/vol
home share

Additional info:

I looked at BZ#202516 and BZ#203277 and didn't think this was similar. Could be
wrong though.

A manual NFS mount of toaster:/vol works:
$ sudo mount toaster:/vol/share /mnt
$ ls /mnt
<lots of files>

syslog entries (automount started with --debug):
Oct  6 10:20:34 riff automount[6351]: Starting automounter version 5.0.1-0.rc2.8
, master map auto.master
Oct  6 10:20:34 riff automount[6351]: mounted autofs indirect mount on /misc
Oct  6 10:20:34 riff automount[6351]: using kernel protocol version 5.00
Oct  6 10:20:34 riff automount[6351]: using timeout 300 seconds; freq 75 secs
Oct  6 10:20:34 riff automount[6351]: mounted autofs indirect mount on /net
Oct  6 10:20:34 riff automount[6351]: using kernel protocol version 5.00
Oct  6 10:20:34 riff automount[6351]: using timeout 300 seconds; freq 75 secs
Oct  6 10:20:46 riff automount[6351]: attempting to mount entry /net/toaster
Oct  6 10:20:46 riff automount[6351]: lookup_mount: exports lookup failed for to
aster
Oct  6 10:20:46 riff automount[6351]: failed to mount /net/toaster
Comment 1 Ian Kent 2006-10-06 11:57:24 EDT
(In reply to comment #0)
> Description of problem:
> 
> attempting to access a filesystem via the /net mechanism fails 
> 
> Version-Release number of selected component (if applicable):
> 
> autofs-5.0.1-0.rc2.8
> nfs-utils-1.0.9-8.fc6
> kernel-2.6.18-1.2741.fc6
> 
> How reproducible:
> Always
> 
> Steps to Reproduce:
> 1. boot system
> 2. type "ls /net/<known system>/mountpoint
> 
>   
> Actual results:
> [williams@riff ~]$ ls /net/toaster/vol
> ls: /net/toaster/vol: No such file or directory
> 
> 
> Expected results:
> [williams@riff ~]$ ls /net/toaster/vol
> home share
> 
> Additional info:
> 
> I looked at BZ#202516 and BZ#203277 and didn't think this was similar. Could be
> wrong though.
> 
> A manual NFS mount of toaster:/vol works:
> $ sudo mount toaster:/vol/share /mnt
> $ ls /mnt
> <lots of files>
> 
> syslog entries (automount started with --debug):
> Oct  6 10:20:34 riff automount[6351]: Starting automounter version 5.0.1-0.rc2.8
> , master map auto.master
> Oct  6 10:20:34 riff automount[6351]: mounted autofs indirect mount on /misc
> Oct  6 10:20:34 riff automount[6351]: using kernel protocol version 5.00
> Oct  6 10:20:34 riff automount[6351]: using timeout 300 seconds; freq 75 secs
> Oct  6 10:20:34 riff automount[6351]: mounted autofs indirect mount on /net
> Oct  6 10:20:34 riff automount[6351]: using kernel protocol version 5.00
> Oct  6 10:20:34 riff automount[6351]: using timeout 300 seconds; freq 75 secs
> Oct  6 10:20:46 riff automount[6351]: attempting to mount entry /net/toaster
> Oct  6 10:20:46 riff automount[6351]: lookup_mount: exports lookup failed for to
> aster
> Oct  6 10:20:46 riff automount[6351]: failed to mount /net/toaster

Yes, but syslog is not sending daemon.debug anywhere.
Please configure syslog to send daemon.* to a logfile and post the log.

Also post the output of "showmount -e toaster".

Ian

Comment 2 Clark Williams 2006-10-06 12:45:38 EDT
Created attachment 137932 [details]
syslog output of 'automount --debug'

requested log file output
Comment 3 Clark Williams 2006-10-06 12:49:26 EDT
$ /usr/sbin/showmount -e toaster
Export list for toaster:
/vol/share 172.16.16.0/23,192.168.40.0/22
/vol/vol0  172.16.52.225
/vol/home  172.16.16.0/23,192.168.40.0/22
Comment 4 Ian Kent 2006-10-06 13:00:21 EDT
(In reply to comment #2)
> Created an attachment (id=137932) [edit]
> syslog output of 'automount --debug'
> 
> requested log file output

Do you have selinux enabled and in enforcing mode?

If so please enable permissive mode (with "setenforce 0") and
check if this makes a difference. You can re-enable enforcing
mode right after the test with "setenforce 1" if you wish.

Ian
Comment 5 Clark Williams 2006-10-06 13:44:04 EDT
I had SELinux disabled with selinux=0 on the kernel command line. 

Just for grins I booted into enforcing mode (targeted policy) but that didn't
change the behavior.
Comment 6 Ian Kent 2006-10-06 14:04:11 EDT
(In reply to comment #5)
> I had SELinux disabled with selinux=0 on the kernel command line. 
> 
> Just for grins I booted into enforcing mode (targeted policy) but that didn't
> change the behavior.
> 

OK.
I'll see what I can come up with using what I have so far.

Ian
Comment 7 Ian Kent 2006-10-06 14:11:04 EDT
(In reply to comment #6)
> OK.
> I'll see what I can come up with using what I have so far.

btw. changing the line "/net -hosts" to "/net auto.net"
may provide a workaround for you.

Also, which of ips in the exports lines lines matches
your machine?

Ian

Comment 8 Clark Williams 2006-10-06 14:20:17 EDT
Changing from -hosts to auto.net works. I didn't even notice that it had changed...

My host is 172.16.16.120, so 172.16.16.0/23

Thanks for the workaround.
Comment 9 Ian Kent 2006-10-07 00:17:09 EDT
(In reply to comment #8)
> Changing from -hosts to auto.net works. I didn't even notice that it had
changed...
> 
> My host is 172.16.16.120, so 172.16.16.0/23

Having a bit of trouble working out what's wrong here.
Could you post the output of "getent hosts `hostname`" please.

Ian
Comment 10 Ian Kent 2006-10-07 05:06:59 EDT
(In reply to comment #9)
> (In reply to comment #8)
> > Changing from -hosts to auto.net works. I didn't even notice that it had
> changed...
> > 
> > My host is 172.16.16.120, so 172.16.16.0/23
> 
> Having a bit of trouble working out what's wrong here.
> Could you post the output of "getent hosts `hostname`" please.

Aaaha ...

At least I've found a problem that gives the same symptoms
you have reported.

Give the patch below a try.

Ian

> 
> Ian
> 

Comment 11 Ian Kent 2006-10-07 05:10:03 EDT
Created attachment 137967 [details]
Make masked_match independent of hostname for exports comparison.
Comment 12 Ian Kent 2007-02-14 00:51:58 EST
(In reply to comment #11)
> Created an attachment (id=137967) [edit]
> Make masked_match independent of hostname for exports comparison.
> 

Is this problem resolved?
The above patch was applied in autofs-5.0.1-0.rc2.10 and
several other fixes have been applied in this area since.

Ian
Comment 13 Clark Williams 2007-02-15 18:28:50 EST
Sorry, wasn't paying attention. Yes the problem has been resolved.

thanks
Comment 14 Wim ten Have 2013-12-22 05:24:33 EST
I found that this problem again shows under Fedora 20.

Changing /etc/auto.master

/net /etc/auto.net

Restores expected functionality.
Comment 15 Ian Kent 2013-12-23 20:53:20 EST
(In reply to Wim ten Have from comment #14)
> I found that this problem again shows under Fedora 20.
> 
> Changing /etc/auto.master
> 
> /net /etc/auto.net
> 
> Restores expected functionality.

Whatever the current problem is, it's nothing to do with this.
See bug 1038356 if you wish to contribute to the resolution.

Note You need to log in before you can comment on or make changes to this bug.