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:
simple configuration, same users, groups, uid, gid on all maschnines, dns works fine, also all maschines in /etc/hosts, using IP for configuration files
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.
(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
(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
(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
(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
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
Can you post the output from "rpcinfo -p 172.20.10.99" please?
(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.
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
(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
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.
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.