Bug 838668 - f17 auotfs can't access to NFS-Share
f17 auotfs can't access to NFS-Share
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
17
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-09 14:09 EDT by dvs65
Modified: 2013-08-01 13:08 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 13:08:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dvs65 2012-07-09 14:09:18 EDT
Description of problem:

fedora 17 autofs/automount (5.0.6 / 19.fc17) can't access to CentOS 6.2 NFS-Shares. no problem by using the mount-command.
works fine with fedora 16, same maschines, same configuration

can reproduce on any maschine only with f17,
no problem with f16-autofs (5.0.6 / 5.fc16), CentOS 6.2, and other distros.



Version-Release number of selected component (if applicable):
Problem only by using f17-autofs 5.0.6 / 19.fc17

How reproducible:
installing f17 on other maschines show the same problem
installing f16 or other linux-distri don't have the problem
using the same configuration-files on all maschines.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 dvs65 2012-07-09 14:14:21 EDT
simple configuration,
same users, groups, uid, gid on all maschnines,
dns works fine, also all maschines in /etc/hosts,
using IP for configuration files
Comment 2 Ian Kent 2012-07-09 20:37:22 EDT
Can you provide a debug log please.

You can do this by ensuring that the syslog facility, daemon,
is being recorded in the log. Something like:
daemon.*                   /var/log/debug
in the syslog configuration will do that.

Then also set LOGGING="debug" in the autofs configuration.
Comment 3 dvs65 2012-07-10 14:06:52 EDT
(In reply to comment #2)
> Can you provide a debug log please.
> 



Hello

Here are the debug-messeges from syslog when I try to access via the automount-config. The mountpoint /data is fix, post you the autofs-config at the end.
It looks like "mount(nfs): no hosts available" is the problem. But can mount easy by using the mount command.


ls -la /data/data01

Jul 10 19:52:15 wsl-name automount[2770]: handle_packet: type = 3
Jul 10 19:52:15 wsl-name automount[2770]: handle_packet_missing_indirect: token 2, name data01, request pid 2781
Jul 10 19:52:15 wsl-name automount[2770]: attempting to mount entry /data/data01
Jul 10 19:52:15 wsl-name automount[2770]: lookup_mount: lookup(file): looking up data01
Jul 10 19:52:15 wsl-name automount[2770]: lookup_mount: lookup(file): data01 -> -rw,soft,intr,nfs4#011172.20.10.99:/data/data01
Jul 10 19:52:15 wsl-name automount[2770]: parse_mount: parse(sun): expanded entry: -rw,soft,intr,nfs4#011172.20.10.99:/data/data01
Jul 10 19:52:15 wsl-name automount[2770]: parse_mount: parse(sun): gathered options: rw,soft,intr,nfs4
Jul 10 19:52:15 wsl-name automount[2770]: parse_mount: parse(sun): dequote("172.20.10.99:/data/data01") -> 172.20.10.99:/data/data01
Jul 10 19:52:15 wsl-name automount[2770]: parse_mount: parse(sun): core of entry: options=rw,soft,intr,nfs4, loc=172.20.10.99:/data/data01
Jul 10 19:52:15 wsl-name automount[2770]: sun_mount: parse(sun): mounting root /data, mountpoint data01, what 172.20.10.99:/data/data01, fstype nfs, options rw,soft,intr,nfs4
Jul 10 19:52:15 wsl-name automount[2770]: mount_mount: mount(nfs): root=/data name=data01 what=172.20.10.99:/data/data01, fstype=nfs, options=rw,soft,intr,nfs4
Jul 10 19:52:15 wsl-name automount[2770]: mount_mount: mount(nfs): nfs options="rw,soft,intr,nfs4", nobind=0, nosymlink=0, ro=0
Jul 10 19:52:15 wsl-name automount[2770]: get_nfs_info: called with host 172.20.10.99(172.20.10.99) proto tcp version 0x70
Jul 10 19:52:15 wsl-name automount[2770]: get_nfs_info: nfs v4 rpc ping time: 0.000234
Jul 10 19:52:15 wsl-name automount[2770]: get_nfs_info: host 172.20.10.99 cost 233 weight 0
Jul 10 19:52:15 wsl-name automount[2770]: mount(nfs): no hosts available
Jul 10 19:52:15 wsl-name automount[2770]: dev_ioctl_send_fail: token = 2
Jul 10 19:52:15 wsl-name automount[2770]: failed to mount /data/data01




auto.master:
/misc   /etc/auto.misc
/data   /etc/auto.data
/net    -hosts
+dir:/etc/auto.master.d
+auto.master


auto.data:
data01  -rw,soft,intr,nfs4      172.20.10.99:/data/data01


sysconfig/autofs
TIMEOUT=300
BROWSE_MODE="no"
MOUNT_NFS_DEFAULT_PROTOCOL=4
LOGGING="debug"
USE_MISC_DEVICE="yes"


Also the /net and /misc configurations doesn't work



Thanks, Darius
Comment 4 Ian Kent 2012-07-10 23:03:19 EDT
(In reply to comment #3)
> 
> auto.master:
> /misc   /etc/auto.misc
> /data   /etc/auto.data
> /net    -hosts
> +dir:/etc/auto.master.d
> +auto.master
> 
> 
> auto.data:
> data01  -rw,soft,intr,nfs4      172.20.10.99:/data/data01

It doesn't look like it from the log but I'm wondering if
your encountering a recent util-linux bug. Especially since
nfs4 isn't a valid mount option and the bug causes mounts with
invalid options to fail instead of ignoring them.

Try using util-linux-2.21.2-2 which is in the testing repository
and autofs-5.0.6-20 which should get to the testing repository
soon.

Ian
Comment 5 dvs65 2012-07-11 14:10:07 EDT
(In reply to comment #4)


> > auto.data:
> > data01  -rw,soft,intr,nfs4      172.20.10.99:/data/data01
> 
> It doesn't look like it from the log 

Sorry, it is, I only change the hostname bevor posting
I greped for "automount"
The last two blocks are the config files.



>but I'm wondering if
> your encountering a recent util-linux bug.

I don't know.
Is there a known bug in util-linux which causes this?



>Especially since
> nfs4 isn't a valid mount option and the bug causes mounts with
> invalid options to fail instead of ignoring them.

I removed the nfs4 mount option, but nothing changed.


> 
> Try using util-linux-2.21.2-22 which is in the testing repository
> and autofs-5.0.6-20 which should get to the testing repository
> soon.

I will take a look at util-linux-2.21.2-22 and hope there will be soon the autofs-5.0.6-20


Thanks

Denis
Comment 6 Ian Kent 2012-07-11 21:26:46 EDT
(In reply to comment #5)
> 
> >but I'm wondering if
> > your encountering a recent util-linux bug.
> 
> I don't know.
> Is there a known bug in util-linux which causes this?

There was a bug where the sloppy (-s) option wasn't being allowed
when mount was run as a user which caused the build of autofs
to not use the sloppy option. So any mounts with unknown options
would fail.

> 
> 
> 
> >Especially since
> > nfs4 isn't a valid mount option and the bug causes mounts with
> > invalid options to fail instead of ignoring them.
> 
> I removed the nfs4 mount option, but nothing changed.

Maybe this is something else then.

> 
> 
> > 
> > Try using util-linux-2.21.2-22 which is in the testing repository
> > and autofs-5.0.6-20 which should get to the testing repository
> > soon.
> 
> I will take a look at util-linux-2.21.2-22 and hope there will be soon the
> autofs-5.0.6-20

autofs-5.0.6-20 has been pushed to testing.

Ian
Comment 7 dvs65 2012-07-14 08:18:12 EDT
Hi Ian

I installed autofs 5.0.21 from the rawhide-repo and get the same effect.
It doesn't work for me.

Then I take a look for a new version of util-linux but that will change halfe the system for needed dependecies.

After all I made a new installation of f16 and everything works fine.
Can reproduce the problem on any maschine only by using f17 or rawhide.

It looks like there is no problem by looking up for the nfs host, parsing the config files and making a rpc-ping to the host. But then it fails by mounting the hosts exports.

Jul 13 19:46:21 wsl-name automount[590]: handle_packet: type = 3
Jul 13 19:46:21 wsl-name automount[590]: handle_packet_missing_indirect: token 1, name data01, request pid 1366
Jul 13 19:46:21 wsl-name automount[590]: attempting to mount entry /data/data01
Jul 13 19:46:21 wsl-name automount[590]: lookup_mount: lookup(file): looking up data01
Jul 13 19:46:21 wsl-name automount[590]: lookup_mount: lookup(file): data01 -> -rw,soft,intr#011172.20.10.99:/data/data01
Jul 13 19:46:21 wsl-name automount[590]: parse_mount: parse(sun): expanded entry: -rw,soft,intr#011172.20.10.99:/data/data01
Jul 13 19:46:21 wsl-name automount[590]: parse_mount: parse(sun): gathered options: rw,soft,intr
Jul 13 19:46:21 wsl-name automount[590]: parse_mount: parse(sun): dequote("172.20.10.99:/data/data01") -> 172.20.10.99:/data/data01
Jul 13 19:46:21 wsl-name automount[590]: parse_mount: parse(sun): core of entry: options=rw,soft,intr, loc=172.20.10.99:/data/data01
Jul 13 19:46:21 wsl-name automount[590]: sun_mount: parse(sun): mounting root /data, mountpoint data01, what 172.20.10.99:/data/data01, fstype nfs, options rw,soft,intr
Jul 13 19:46:21 wsl-name automount[590]: mount_mount: mount(nfs): root=/data name=data01 what=172.20.10.99:/data/data01, fstype=nfs, options=rw,soft,intr
Jul 13 19:46:21 wsl-name automount[590]: mount_mount: mount(nfs): nfs options="rw,soft,intr", nobind=0, nosymlink=0, ro=0
Jul 13 19:46:21 wsl-name automount[590]: get_nfs_info: called with host 172.20.10.99(172.20.10.99) proto tcp version 0x70
Jul 13 19:46:21 wsl-name automount[590]: get_nfs_info: nfs v4 rpc ping time: 0.000307
Jul 13 19:46:21 wsl-name automount[590]: get_nfs_info: host 172.20.10.99 cost 307 weight 0
Jul 13 19:46:21 wsl-name automount[590]: mount(nfs): no hosts available
Jul 13 19:46:21 wsl-name automount[590]: dev_ioctl_send_fail: token = 1
Jul 13 19:46:21 wsl-name automount[590]: failed to mount /data/data01


If I did it with the mount comand, there is no problem.

[root@wsl-name ~]# mkdir /media/test
[root@wsl-name ~]# mount 172.20.10.99:/data/data01 /media/test
[root@wsl-name ~]# ls -la /media/test
insgesamt 32
drwxrwxr-x.  9 root  users 4096 22. Apr 12:36 .
drwxr-xr-x.  3 root  root    60 14. Jul 13:40 ..
drwxrwxr-x.  6 root users 4096 25. Jun 2011  bu-name-20120411
drwxr-xr-x. 11 root  root  4096 21. Apr 17:16 conf
drwxrwxr-x. 12 root  root  4096  6. Mär 2011  conf-2011
drwxr-xr-x.  6 root users 4096 16. Mai 13:42 name
drwxrwxr-x.  2 root  root  4096  1. Feb 19:44 lost+found
drwxrwxr-x.  4 root  root  4096 17. Apr 12:39 .Trash-0
drwxrwxr-x.  7 root users 4096 25. Feb 2011  vm


Now I searched for the problem over 1 month. 
1 month, that I can't use my workstation, because using nfs-filesystems is a basic service for me. It is also the basic for the backup and recovery-services at my network.

Sorry, I surrender.
Need an up2date (not bleeding edge) system, stable and functionel but f17 isn't that to me.
Had many other problems with f17 which wasn't there with f16 or other distros, like the selinux-pre-configuration by using kde and so on.
Getting back to f16 or looking for new ways.


Thanks for your efforts.


Darius
Comment 8 Ian Kent 2012-07-15 22:00:57 EDT
Can you post the output from "rpcinfo -p 172.20.10.99" please?
Comment 9 Ian Kent 2012-07-15 22:30:43 EDT
(In reply to comment #7)
> Hi Ian
> 
> I installed autofs 5.0.21 from the rawhide-repo and get the same effect.
> It doesn't work for me.
> 
> Then I take a look for a new version of util-linux but that will change
> halfe the system for needed dependecies.

If you build the autofs srpm as root user on your machine you
don't need to update util-linux.
Comment 10 dvs65 2012-07-18 13:45:42 EDT
Hi,


I've got it.
One of my first thought was that it may be an rpc-problem . . .
. . . and it was.

You last question took me to the right things.

If you are coniguring NFS on CentOS 6.x there is a point in the firewall-rules with that you can open the ports for nfs (2049). But what they dont' think about was that also rpc need to have an open port 111.
I open that port and everything was fine.

But I_m wondering that older versions of autofs/auotmount seem to have no problems when port 111 is closed on the server.
It looks like that older versions of autofs don't need to check the server over rpc befor mounting the volumes. Autofs shiped with f17 do that and that was the problem.

Thank you for giving me the right reference.


Denis
Comment 11 Ian Kent 2012-07-18 23:43:46 EDT
(In reply to comment #10)
> Hi,
> 
> 
> I've got it.
> One of my first thought was that it may be an rpc-problem . . .
> . . . and it was.
> 
> You last question took me to the right things.
> 
> If you are coniguring NFS on CentOS 6.x there is a point in the
> firewall-rules with that you can open the ports for nfs (2049). But what
> they dont' think about was that also rpc need to have an open port 111.
> I open that port and everything was fine.

Right, that's going to make things difficult for people.

I didn't get that either and if I had realized it I would have
recommended you set the autofs configuration entry MOUNT_WAIT
to a value other than the default of -1, which would bypass the
server probe code for simple mounts, as it did previously.

> 
> But I_m wondering that older versions of autofs/auotmount seem to have no
> problems when port 111 is closed on the server.

Yes but mount.nfs might have had a problem at times.

> It looks like that older versions of autofs don't need to check the server
> over rpc befor mounting the volumes. Autofs shiped with f17 do that and that
> was the problem.

That's right, at least for mounts that involve a single server.

The reason for the change is due to reports of mounts to servers
that aren't responding taking a long time to time out. That's due
to changes to mount.nfs where it now lets the kernel take care of
performing the options processing. But the kernel must handle rpc
a little differently than user space and that leads to the lengthy
timeouts if the server isn't responding.

Consequently the server availability check was re-instated and the
error return handling improved so that we can mostly avoid the long
waits.

Ian
Comment 12 Fedora End Of Life 2013-07-04 01:51:58 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2013-08-01 13:08:23 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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