Created attachment 453531 [details] All steps I took about NFS setting and logs for autofs. Description of problem: After setting up the NFS4 server and clients, I cannot auto-mount the specified directory on NFS4 server from NFS4 client. Version-Release number of selected component (if applicable): autofs 5.0.1 or 5.0.5 How reproducible: Always Steps to Reproduce: See the attached file for details. 1. Set up NFS4 server with exporting /home with fsid=0. 2. Set up NFS4 client with "/net -hosts -fstype=nfs4" in /etc/auto.master. 3. I cannot auto-mount NFSserver:/home from NFSclient side using /net/NFSserver. Actual results: NFSclient> ll /net/NFSserver ls: /net/NFSserver: No such file or directory Expected results: NFSclient> ll /net/NFSserver total 0 drwxr-xr-x 7 root root 4096 Oct 13 15:42 home Additional info: NFSserver= RHEL 5.4, NFSclients= RHEL 5.4 & 6.0 beta 2
(In reply to comment #0) > Created attachment 453531 [details] > All steps I took about NFS setting and logs for autofs. > > Description of problem: > After setting up the NFS4 server and clients, I cannot auto-mount the specified > directory on NFS4 server from NFS4 client. > > Version-Release number of selected component (if applicable): > autofs 5.0.1 or 5.0.5 > > How reproducible: > Always > > Steps to Reproduce: > See the attached file for details. > 1. Set up NFS4 server with exporting /home with fsid=0. > 2. Set up NFS4 client with "/net -hosts -fstype=nfs4" in /etc/auto.master. > 3. I cannot auto-mount NFSserver:/home from NFSclient side using > /net/NFSserver. That's right, this is because when using a Linux NFS server prior to RHEL-6, the global root NFSv4 export path generally does not match the path that is exported to client systems. In RHEL-6 the NFS server now allows the export to be mounted using the path present in the export or the path relative to the NFSv4 global root. From the client the information provided with the list of exports has no information about supported NFS versions or fsid so there is no way to know if we need to try and work out what the global root is. What's worse is that the export with fsid=0 doesn't have to be the shortest path exported so the NFSv4 global root cannot be inferred this way either. After speaking about this with support recently I've been thinking about possibly trying to handle some limited cases for this but it is not easy to do and could easily adversely impact existing functionality. I've set the status to ASSIGNED and set devel_ack+ but I'm still not sure if I will be able to help with this. Ian
(In reply to comment #1) Thank you for your detailed reply. Since I am new in this field and I am not sure that I understand fully what you describe, but can I conclude as follows? A. The NFSv4 server on RHEL 5 or lower does not support the NFSv4 client to use the [/net -hosts -fstype=nfs4]-automount function. B. There is a way to use automount with NFSv4 by defining a mount command in a separate automount file, which is [/nfs4 /etc/auto.nfs4]-automount function. Since our third party software company strongly recommends to use the automount function "/net -hosts", I tried to use it with NFSv4 instead of NFSv2,3. They suggest to use NFSv2,3 with no firewall, which I want to avoid. If it is not possible, however, to use [/net -hosts]-automount feature together with NFSv4, I just give it up until this company supports RHEL 6. Starnge thing is the following. 1. Even if I specify -fstype=nfs4 in /etc/auto.master, autofs uses portmap on the NFSv4 client. If I stop portmapper on the NFSv4 client, even above B automount does not work. Does NFSv4 require portmapper on the client? 2. The above happens on RHEL 5.4 NFSv4 client. Since I do not know how to stop portmap daemon on RHEL 6 (there is no /etc/init.d/portmap any longer on RHEL 6.0), I cannot tell this about RHEL 6 NFSv4 client. 3. Once I start nfsd4 on NFSv4 server, I do not need portmapper on NFSv4 server any longer; I mean, the NFSv4 client can automount the exported NFSv4 server directory without portmapper on NFSv4 server. Thank you for your taking care of this. Toshi
(In reply to comment #2) > (In reply to comment #1) > Thank you for your detailed reply. Since I am new in this field and I am not > sure that I understand fully what you describe, but can I conclude as follows? > A. The NFSv4 server on RHEL 5 or lower does not support the NFSv4 client to use > the [/net -hosts -fstype=nfs4]-automount function. Yes, that's right. With RHEL-6 and later this should work fine and the option "fstype=nfs4" also should not be needed because NFSv4 is the default NFS version for mounts in RHEL-6. > B. There is a way to use automount with NFSv4 by defining a mount command in a > separate automount file, which is [/nfs4 /etc/auto.nfs4]-automount function. If you write a program map that can adjust the path to account for the NFSv4 global root then yes. This would likely do the same thing as I'm planning to try. For the case of the hosts map where NFSv4 is specified (the fstype=nfs4) then we can assume that the server is set up with "all" its exports as NFSv4. In this case, the shortest export path should be the NFSv4 global root and we can adjust the mount location path appropriately for each mount within the autofs hosts map lookup module. I believe NFS servers, other than earlier Linux servers, support mounting using the NFSv4 global root or the actual export path but I need to confirm that before trying this change. > > Since our third party software company strongly recommends to use the automount > function "/net -hosts", I tried to use it with NFSv4 instead of NFSv2,3. They > suggest to use NFSv2,3 with no firewall, which I want to avoid. > If it is not possible, however, to use [/net -hosts]-automount feature together > with NFSv4, I just give it up until this company supports RHEL 6. > > Starnge thing is the following. > 1. Even if I specify -fstype=nfs4 in /etc/auto.master, autofs uses portmap on > the NFSv4 client. If I stop portmapper on the NFSv4 client, even above B > automount does not work. Does NFSv4 require portmapper on the client? NFSv4 should not need to contact a portmap server and, in this case, autofs shouldn't be trying to contact a portmap server either. mount(8) (in this case mount.nfs(8)) also shouldn't need to contact a portmap server but we would need to check further to work out what is happening. > 2. The above happens on RHEL 5.4 NFSv4 client. Since I do not know how to stop > portmap daemon on RHEL 6 (there is no /etc/init.d/portmap any longer on RHEL > 6.0), I cannot tell this about RHEL 6 NFSv4 client. Yes, that's right. RHEL-6 uses rpcbind for port mapping. Look for /etc/init.d/rpcbind. > 3. Once I start nfsd4 on NFSv4 server, I do not need portmapper on NFSv4 server > any longer; I mean, the NFSv4 client can automount the exported NFSv4 server > directory without portmapper on NFSv4 server. Yes, NFSv4 is supposed to be able to function without the need to consult a network port mapping server so that it can function within a environment were network access is restricted in some way. I believe that, in this case, the NFS server must be using the well known NFS service port (2049) to provide its service. Ian
(In reply to comment #3) Thank you very much for your reply. Your comments/statements/instructions are always very helpful and useful, not only in this Bugzilla but also in other web sites, such as http://lwn.net/Articles/350837/. > (In reply to comment #2) > > (In reply to comment #1) > > B. There is a way to use automount with NFSv4 by defining a mount command in a > > separate automount file, which is [/nfs4 /etc/auto.nfs4]-automount function. > > If you write a program map that can adjust the path to account > for the NFSv4 global root then yes. This would likely do the > same thing as I'm planning to try. > I am simply thinking about the automount map as follows, which works fine as I expected. root@client# cat /etc/auto.master /nfs4 /etc/auto.nfs4 root@client# cat /etc/auto.nfs4 home -fstype=nfs4,nodev,nosuid,nonstrict,sync,_netdev,proto=tcp,retry=10, rsize=8192,wsize=8192,intr,hard NFSserver:/ Or equivalently the following; similar effect to "/net -hosts". root@client# cat /etc/auto.master /net/NFSserver1 /etc/auto.NFSserver1 root@client# cat /etc/auto.NFSserver1 home -fstype=nfs4,nodev,nosuid,nonstrict,sync,_netdev,proto=tcp,retry=10, rsize=8192,wsize=8192,intr,hard NFSserver1:/ ++++++ > > Starnge thing is the following. > > 1. Even if I specify -fstype=nfs4 in /etc/auto.master, autofs uses portmap on > > the NFSv4 client. If I stop portmapper on the NFSv4 client, even above B > > automount does not work. Does NFSv4 require portmapper on the client? > > NFSv4 should not need to contact a portmap server and, in this > case, autofs shouldn't be trying to contact a portmap server > either. mount(8) (in this case mount.nfs(8)) also shouldn't > need to contact a portmap server but we would need to check > further to work out what is happening. > Thank you very much. > > 2. The above happens on RHEL 5.4 NFSv4 client. Since I do not know how to stop > > portmap daemon on RHEL 6 (there is no /etc/init.d/portmap any longer on RHEL > > 6.0), I cannot tell this about RHEL 6 NFSv4 client. > > Yes, that's right. RHEL-6 uses rpcbind for port mapping. > Look for /etc/init.d/rpcbind. > Thank you. Now I can stop portmapper on RHEL-6 and found that on RHEL-6 NFSv4- client, I could automount NFSv4-server-directory even if portmapper is not working on NFSv4-client. > > 3. Once I start nfsd4 on NFSv4 server, I do not need portmapper on NFSv4 server > > any longer; I mean, the NFSv4 client can automount the exported NFSv4 server > > directory without portmapper on NFSv4 server. > > Yes, NFSv4 is supposed to be able to function without > the need to consult a network port mapping server so > that it can function within a environment were network > access is restricted in some way. I believe that, in > this case, the NFS server must be using the well known > NFS service port (2049) to provide its service. > Yes, it is as follows. root@NFSserver# rpcinfo -p program vers proto port ............. 100003 4 tcp 2049 nfs 100003 4 udp 2049 nfs ............. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ One more thing I forgot writing last time is as follows. It looks that the files, hosts.deny and hosts.allow, on RHEL-5 NFSv4-server are ignored when I automount the directory of NFSv4 server from the client. On (RHEL-5 or RHEL-6) NFSv4-client, I can automount the directory even when NFSv4 server has the followings. I can connect to this NFSv4 server through ssh. root@server# cat /etc/hosts.deny ALL: ALL root@server# cat /etc/hosts.allow # nfsd: NFSv4-client/255.255.255.255 # nfsd4: NFSv4-client/255.255.255.255 sshd: NFSv4-client/255.255.255.255 Of course, I can automount the directory under the following files as well, but I cannot connect to this NFSv4-server now due to "# sshd:...". root@server# cat /etc/hosts.deny ALL: ALL root@server# cat /etc/hosts.allow nfsd: NFSv4-client/255.255.255.255 nfsd4: NFSv4-client/255.255.255.255 # sshd: NFSv4-client/255.255.255.255 It looks sshd watches the hosts.deny and hosts.allow while nfsd4 does not. I am waiting for RHEL-6 official release (^_^). Thank you for your time. Toshi
(In reply to comment #4) > > > > If you write a program map that can adjust the path to account > > for the NFSv4 global root then yes. This would likely do the > > same thing as I'm planning to try. > > > > I am simply thinking about the automount map as follows, which works fine as I > expected. > root@client# cat /etc/auto.master > /nfs4 /etc/auto.nfs4 > root@client# cat /etc/auto.nfs4 > home -fstype=nfs4,nodev,nosuid,nonstrict,sync,_netdev,proto=tcp,retry=10, > rsize=8192,wsize=8192,intr,hard NFSserver:/ > > Or equivalently the following; similar effect to "/net -hosts". > root@client# cat /etc/auto.master > /net/NFSserver1 /etc/auto.NFSserver1 > root@client# cat /etc/auto.NFSserver1 > home -fstype=nfs4,nodev,nosuid,nonstrict,sync,_netdev,proto=tcp,retry=10, > rsize=8192,wsize=8192,intr,hard NFSserver1:/ Sure, I believe this would do what you need. If there are additional exports below NFSserver1:/ and they are exported with the "nohide" option the kernel NFS client will also automatically mount these on access. However, autofs will not know about these and they will not show in /etc/mtab. They will of course show up in /proc/mounts. I can't be certain but I believe autofs will still expire this mount correctly but we will have to try it out. snip ... > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > One more thing I forgot writing last time is as follows. > It looks that the files, hosts.deny and hosts.allow, on RHEL-5 NFSv4-server are > ignored when I automount the directory of NFSv4 server from the client. > On (RHEL-5 or RHEL-6) NFSv4-client, I can automount the directory even when > NFSv4 server has the followings. I can connect to this NFSv4 server through > ssh. > root@server# cat /etc/hosts.deny > ALL: ALL > root@server# cat /etc/hosts.allow > # nfsd: NFSv4-client/255.255.255.255 > # nfsd4: NFSv4-client/255.255.255.255 > sshd: NFSv4-client/255.255.255.255 > Of course, I can automount the directory under the following files as well, but > I > cannot connect to this NFSv4-server now due to "# sshd:...". > root@server# cat /etc/hosts.deny > ALL: ALL > root@server# cat /etc/hosts.allow > nfsd: NFSv4-client/255.255.255.255 > nfsd4: NFSv4-client/255.255.255.255 > # sshd: NFSv4-client/255.255.255.255 > > It looks sshd watches the hosts.deny and hosts.allow while nfsd4 does not. > I am waiting for RHEL-6 official release (^_^). Not sure about this. Perhaps Bruce Fields can advise us on this (added to the CC list)? Ian
Another problem can arise when the export you wish to mount is present on the local machine. In this case autofs will try and perform a bind mount with the incorrect location path. A way to work around this is to use the autofs pseudo mount option "nosymlink". This option will prevent autofs from using a bind mount for local mounts. I'm pretty sure this option isn't documented and it won't be since it is very old and probably should now be called "nobind". At some point I will need to add the option "nobind" for this purpose and document it in the man pages.
(In reply to comment #5) > (In reply to comment #4) > > > > > > If you write a program map that can adjust the path to account > > > for the NFSv4 global root then yes. This would likely do the > > > same thing as I'm planning to try. > > > > > > > I am simply thinking about the automount map as follows, which works fine as I > > expected. > > root@client# cat /etc/auto.master > > /nfs4 /etc/auto.nfs4 > > root@client# cat /etc/auto.nfs4 > > home -fstype=nfs4,nodev,nosuid,nonstrict,sync,_netdev,proto=tcp,retry=10, > > rsize=8192,wsize=8192,intr,hard NFSserver:/ > > > > Or equivalently the following; similar effect to "/net -hosts". > > root@client# cat /etc/auto.master > > /net/NFSserver1 /etc/auto.NFSserver1 > > root@client# cat /etc/auto.NFSserver1 > > home -fstype=nfs4,nodev,nosuid,nonstrict,sync,_netdev,proto=tcp,retry=10, > > rsize=8192,wsize=8192,intr,hard NFSserver1:/ > > Sure, I believe this would do what you need. Thank you very much. I will use this. > If there are additional exports below NFSserver1:/ and they > are exported with the "nohide" option the kernel NFS client > will also automatically mount these on access. However, autofs > will not know about these and they will not show in /etc/mtab. > They will of course show up in /proc/mounts. > > I can't be certain but I believe autofs will still expire this > mount correctly but we will have to try it out. When I need this, I will try it. Thank you for your advice. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > One more thing I forgot writing last time is as follows. > > It looks that the files, hosts.deny and hosts.allow, on RHEL-5 NFSv4-server are > > ignored when I automount the directory of NFSv4 server from the client. > > On (RHEL-5 or RHEL-6) NFSv4-client, I can automount the directory even when > > NFSv4 server has the followings. I can connect to this NFSv4 server through > > ssh. > > root@server# cat /etc/hosts.deny > > ALL: ALL > > root@server# cat /etc/hosts.allow > > # nfsd: NFSv4-client/255.255.255.255 > > # nfsd4: NFSv4-client/255.255.255.255 > > sshd: NFSv4-client/255.255.255.255 > > Of course, I can automount the directory under the following files as well, but > > I > > cannot connect to this NFSv4-server now due to "# sshd:...". > > root@server# cat /etc/hosts.deny > > ALL: ALL > > root@server# cat /etc/hosts.allow > > nfsd: NFSv4-client/255.255.255.255 > > nfsd4: NFSv4-client/255.255.255.255 > > # sshd: NFSv4-client/255.255.255.255 > > > > It looks sshd watches the hosts.deny and hosts.allow while nfsd4 does not. > > I am waiting for RHEL-6 official release (^_^). > > Not sure about this. > Perhaps Bruce Fields can advise us on this (added to the CC > list)? Thank you for CCing. (In reply to comment #6) > Another problem can arise when the export you wish to mount > is present on the local machine. In this case autofs will > try and perform a bind mount with the incorrect location > path. > > A way to work around this is to use the autofs pseudo mount > option "nosymlink". This option will prevent autofs from > using a bind mount for local mounts. I'm pretty sure this > option isn't documented and it won't be since it is very > old and probably should now be called "nobind". At some > point I will need to add the option "nobind" for this > purpose and document it in the man pages. Thank you; I will keep this "nobind (nosymlink)" option in mind. Thank you very much for you quick and detailed comments. Toshi
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
> > It looks sshd watches the hosts.deny and hosts.allow while nfsd4 does not. > > I am waiting for RHEL-6 official release (^_^). > > Not sure about this. > Perhaps Bruce Fields can advise us on this (added to the CC > list)? Apologies, I think I missed this comment before. The kernel nfsd can't of course link against libwrap. If v3 mounts fail due to libwrap checks then that's because they first try to contact rpc.mountd, which does use libwrap and enforce hosts.allow/hosts.deny. Without looking far into it--it may be possible to address this by adding a call to check_default() (or something like it) in nfs-utils/utils/mountd/cache.c:auth_unix_ip(), thus failing the kernel's upcall to resolve the name of the incoming client. If that's desirable, I'd recommend opening another bug for that.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
Re-reading this bug I believe there is no defined work to be done. Bruce did recommend raising a new bug for one possible issue but that's not to be handled here. So I'm closing this as NOTABUG. If that isn't correct please re-open the bug with a comment about what we needs to be done. Ian
(In reply to comment #11) > Re-reading this bug I believe there is no defined work to > be done. Bruce did recommend raising a new bug for one > possible issue but that's not to be handled here. > > So I'm closing this as NOTABUG. > If that isn't correct please re-open the bug with a comment > about what we needs to be done. > > Ian I understood that you were looking to make adjustments based on this from comment#3 : "If you write a program map that can adjust the path to account for the NFSv4 global root then yes. This would likely do the same thing as I'm planning to try. For the case of the hosts map where NFSv4 is specified (the fstype=nfs4) then we can assume that the server is set up with "all" its exports as NFSv4. In this case, the shortest export path should be the NFSv4 global root and we can adjust the mount location path appropriately for each mount within the autofs hosts map lookup module." ..and also this from comment#6 : "At some point I will need to add the option "nobind" for this purpose and document it in the man pages." However, if the workarounds discussed in comment#5 are equally valid methods, and have been fully tested and proven to work by Red Hat, then I guess we can simply document how to have autofs+nfsv4 working correctly and in a supported manner in manpage and kbase?
(In reply to comment #12) > > I understood that you were looking to make adjustments based on this from > comment#3 : > > "If you write a program map that can adjust the path to account for the NFSv4 > global root then yes. This would likely do the same thing as I'm planning to > try. > > For the case of the hosts map where NFSv4 is specified (the fstype=nfs4) then > we can assume that the server is set up with "all" its exports as NFSv4. In > this case, the shortest export path should be the NFSv4 global root and we can > adjust the mount location path appropriately for each mount within the autofs > hosts map lookup module." Yes, I would have liked to do that but there is also no way to know what OS is on the server at the other end which would just introduce further incompatibilities. For consistent fall back from NFSv4 to NFSv3 or v2 and consistent mounting of shares that are remote (and possibly on servers with different OSs) or mounting shares that are local the path needs to match that given in server exports. There's just no real way around that. After quite a bit of thought on this I'm afraid I'm going to have to stubbornly stick to this. > > ..and also this from comment#6 : > > "At some point I will need to add the option "nobind" for this purpose and > document it in the man pages." That's been the case for a long time. I will get to this one day but it hasn't been a priority. If it really annoys you please feel free to log a service call about it and then I'll need to get to it sooner rather than later. > > However, if the workarounds discussed in comment#5 are equally valid methods, > and have been fully tested and proven to work by Red Hat, then I guess we can > simply document how to have autofs+nfsv4 working correctly and in a supported > manner in manpage and kbase? The workarounds in comment #5 should be fine. I haven't yet tested the expiration but from what I understand of the kernel the worst that should happen is an automount expire failing with an EBUSY which should is handled by automount. I'm not sure that man page changes are appropriate since all NFS servers should appear to behave the same way and earlier versions of the Linux NFS server are the odd system out and it has been changed so the issue will go away over time. I think a kbase article that documents the issues and ways to handle them is by far the best way to deal with this. That would allow us to collect information here and other methods people have used worked around this in a single location for RHEL users. I'll have a talk with our SEG people to see how to go about this. Ian
Created attachment 523999 [details] Commented text from docspace article I have added several paragraphs bracketed by "edit: imk ... end edit:imk". Have a read and send any questions.
Created attachment 524168 [details] docspace article, new version
Created attachment 526199 [details] docspace article, new version 2
I agreed with the customer to provide a first version of the document the next days. Will do that on Thursday. I pointed out that this might not be the definite settled version and change, but customer is keen on finally seeing something..
The document in current state can be accessed at https://access.redhat.com/kb/docs/DOC-65205 .
A bug was found in the modified /etc/auto.net.nfs4 . Verifying a corrected version with the customer. Old code: sed -e 's,:/.[^\s]*,:/ ,' new code: sed -e 's,:/.[^ ]*,:/ ,'
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
(In reply to comment #34) > A bug was found in the modified /etc/auto.net.nfs4 . > Verifying a corrected version with the customer. > > Old code: > sed -e 's,:/.[^\s]*,:/ ,' > new code: > sed -e 's,:/.[^ ]*,:/ ,' Oh, I get it, the \s doesn't match white space (space or tab) in sed, oops! I guess an embedded tab character is not very likely and the old code will break if an "s" is present in the path so the new code is is certainly better than the old code.
Seems the flags and bug data were changed by mistake when add above comment, I will reset them. Ian Kent <ikent> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|autofs |autofs Version|5.4 |6.3 Product|Red Hat Enterprise Linux 5 |Red Hat Enterprise Linux 6 QA Contact|yanwang |kernel-qe Flags|needinfo?(ikent) | Flags|rhel-5.9.0+ | Flags|qa_ack+ | Flags| |qa_ack? Flags|pm_ack+ | Flags| |pm_ack?
Set to verify since the document modified as per above comments, and customer and developer both confirm it.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0132.html