Description of problem: NFS network shared directories that are automatically mounted in /net on a client are disconnected or dropped after about one hour or none use after initial connect at boot. Restarting autofs reconnects the shares. Version-Release number of selected component (if applicable): all fc6 versions up to and including autofs-5.0.1-0.rc3.2 How reproducible: Share some directories on a server; in my case, /mnt/6B200P0/storage and some other subdirectories of /mnt/6B200P0. Server is SME 7.0/7.1, a RHEL derivative (and worked fine with fc5). Connect an fc6 client to the network, shares automatically appear on /net . After about an hour, shares disconnect and are inaccessible unless autofs is restarted. Other fc6 clients on the same network using the same shares do not lose the connection; these clients mount the NFS shares in fstab though, and, FWIW, use NFS homes.
(In reply to comment #0) > Description of problem: NFS network shared directories that are automatically > mounted in /net on a client are disconnected or dropped after about one hour or > none use after initial connect at boot. Restarting autofs reconnects the shares. Your description of this is a bit unclear to me but it sounds like you are seeing the same as described in 222872. Can you check that bug and let me know please. Ian
Ian; Maybe I am misunderstanding what happens. I assume that autofs mounts shares in /net and leaves them mounted. I gather I'm wrong in my assumption. What really happens is that autofs mounts shares in /net and unmounts them after a period of time (five minutes). It will remount them when they are requested, but bug #222872 is stating that the remount does not occur as expected. Is that correct? If so, then the behavior I'm seeing is the same as what is described in 222872, so the bug I've filed is a duplicate.
(In reply to comment #2) > Ian; > > Maybe I am misunderstanding what happens. I assume that autofs mounts shares in > /net and leaves them mounted. I gather I'm wrong in my assumption. What really > happens is that autofs mounts shares in /net and unmounts them after a period of > time (five minutes). It will remount them when they are requested, but bug > #222872 is stating that the remount does not occur as expected. Is that correct? Yes that's the way it's supposed to work, the default timeout is 5 minutes. The problem only happens occassionally to one or two of the mounts but becuase of the dependencies in the mounts it stops other mounts from working properly. Ian
You will see autofs-5.0.1-0.rc3.8 appear in Fedora updates testing soon. Could you give it a try please. Ian
Ian; Same issues with autofs-5.0.1-0.rc3.8 . Are there any logs I can send you that would help? -Pete
(In reply to comment #5) > Ian; > > Same issues with autofs-5.0.1-0.rc3.8 . Are there any logs I can send you that > would help? Got one from bug 222872, thanks anyway. autofs-5.0.1-0.rc3.10 is on it's way to testing. Please give it a try. Ian
Ian; autofs-5.0.1-0.rc3.10 seems to resolve the problem for me. I haven't had a problem with reconnecting shares since I installed the update about three hours ago. One other minor issue (still) is that when I open a Nautilus browser to see the shares, which I have linked from /net/192.168.1.1/whatever, I get the little lock icons on some of the shares. Right clicking to check permissions makes them vanish, as does refreshing the view. Again, a minor problem but one that didn't exist in FC5. I didn't install the debug package for .10 . Would you like me to, and is there some log info I can send you to make sure the fix is working right? -Pete
(In reply to comment #7) > Ian; > > autofs-5.0.1-0.rc3.10 seems to resolve the problem for me. I haven't had a > problem with reconnecting shares since I installed the update about three hours ago. That's good. > > One other minor issue (still) is that when I open a Nautilus browser to see the > shares, which I have linked from /net/192.168.1.1/whatever, I get the little > lock icons on some of the shares. Right clicking to check permissions makes them > vanish, as does refreshing the view. Again, a minor problem but one that didn't > exist in FC5. Sounds strange. But it is a different problem and we need to stick to one problem at a time in any given bz otherwise we'll get confused. If you can get more information then log another bz to have it investigated. > > I didn't install the debug package for .10 . Would you like me to, and is there > some log info I can send you to make sure the fix is working right? That is just there for completeness. It's only really usefull if we need to run gdb on an autofs core file. The problem that this resolved was quite clear in the end and a silly programming error. It was introduced about the 27th Dec so it mathces with other info about when the problem started. The lack of the problem and the absence of the error messages in the log should be enough but thanks anyway. We have the other report for additional verification also. Ian
Ian; Might need to open a new bug or reopen 222872. I notice now that when I'm connected to my network where my NFS shares are automounted, automount fails to stop at shutdown. This is with autofs-5.0.1-0.rc3.10. If I connect to a network that doesn't have any NFS shares, automount stops normally during shutdown.
(In reply to comment #9) > Ian; > > Might need to open a new bug or reopen 222872. I notice now that when I'm > connected to my network where my NFS shares are automounted, automount fails to > stop at shutdown. This is with autofs-5.0.1-0.rc3.10. If I connect to a network > that doesn't have any NFS shares, automount stops normally during shutdown. I'd need a debug log. See http://people.redhat.com/jmoyer for a description on how to do this. Ian
Ian; All I'm getting in /var/log/debug relating to automount is this: Jan 26 08:23:24 pc-00105 automount[4952]: lookup_read_master: lookup(nisplus): couldn't locat nis+ table auto.master Also looks like a spelling mistake there, "locat" should be 'locate"? -Pete
(In reply to comment #11) > Ian; > > All I'm getting in /var/log/debug relating to automount is this: > > Jan 26 08:23:24 pc-00105 automount[4952]: lookup_read_master: lookup(nisplus): > couldn't locat nis+ table auto.master If you don't use nisplus then remove it from the list of sources in your nsswitch configuration. Ian
I can't do anything more on this until I get a look at a debug log. Ian
(In reply to comment #13) > I can't do anything more on this until I get a look at a debug > log. > The debug log you sent looks like you may have a broken nfs-utils or nfs-utils-lib. Do you have the latest revisions installed? Ian
Ian; [pjones@pc-00105 ~]$ rpm -qa nfs-utils nfs-utils-1.0.10-5.fc6 [pjones@pc-00105 ~]$ rpm -qa nfs-utils-lib nfs-utils-lib-1.0.8-7.2 -Pete
(In reply to comment #14) > (In reply to comment #13) > > I can't do anything more on this until I get a look at a debug > > log. > > > > The debug log you sent looks like you may have a broken > nfs-utils or nfs-utils-lib. Do you have the latest revisions > installed? Could you send a debug log wich shows a mount and an normal expire of a problem filesystem before attempting to shutdown. Ian > > Ian >
(In reply to comment #16) > (In reply to comment #14) > > (In reply to comment #13) > > > I can't do anything more on this until I get a look at a debug > > > log. > > > > > > > The debug log you sent looks like you may have a broken > > nfs-utils or nfs-utils-lib. Do you have the latest revisions > > installed? > > Could you send a debug log wich shows a mount and an normal > expire of a problem filesystem before attempting to shutdown. Also, you don't say what you did before restarting autofs. Was automount still running or had it gone away? Did you kill it? Are there any core files, possibly in the root directory? Ian
Ian; OK, here's how I use automount/NFS directories, for what it may be worth. I have FC6 on my laptop, use a stock FC6 GNOME as my desktop, and I link to the automount directories that appear in /net to subdirectories in a directory in my /home/pjones directory. So, /home/pjones/server/stuff is linked to /net/192.168.1.1/mnt/stuff . When I was having the orignal disconnect/no reconnect problem with autofs-5.0.1-0.rc3.2, these links would obviously cease to work. I would check in /net and see /net/192.168.1.1/mnt there, but continuing to drill down would show that the other subdirectories were no longer there. Then I would do, as root, a 'service autofs restart', and then they would reappear. This behavior is fixed in the recent autofs-5.0.1-0.rc3.10. I am not able to find any core files.
I think this problem should be fixed in the current revision of autofs. Can you check please? Ian
Ian; With autofs-5.0.1-0.rc3.19 everything seems to be working as expected. Thanks, -Pete