Bug 209638 - mount of /net mountpoint failed due to exports lookup failure
Summary: mount of /net mountpoint failed due to exports lookup failure
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Ian Kent
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-06 15:43 UTC by Clark Williams
Modified: 2013-12-24 01:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-15 23:28:50 UTC
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 16:45 UTC, Clark Williams
no flags Details
Make masked_match independent of hostname for exports comparison. (3.76 KB, patch)
2006-10-07 09:10 UTC, Ian Kent
no flags Details | Diff

Description Clark Williams 2006-10-06 15:43:00 UTC
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 15:57:24 UTC
(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 16:45:38 UTC
Created attachment 137932 [details]
syslog output of 'automount --debug'

requested log file output

Comment 3 Clark Williams 2006-10-06 16:49:26 UTC
$ /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 17:00:21 UTC
(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 17:44:04 UTC
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 18:04:11 UTC
(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 18:11:04 UTC
(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 18:20:17 UTC
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 04:17:09 UTC
(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 09:06:59 UTC
(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 09:10:03 UTC
Created attachment 137967 [details]
Make masked_match independent of hostname for exports comparison.

Comment 12 Ian Kent 2007-02-14 05:51:58 UTC
(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 23:28:50 UTC
Sorry, wasn't paying attention. Yes the problem has been resolved.

thanks


Comment 14 Wim ten Have 2013-12-22 10:24:33 UTC
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-24 01:53:20 UTC
(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.