Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Here is the situation:
I have a maintaining computers for our research lab, almost every computer is assigned to specific person; however, sometimes there is a need to share the computers.
So we have NIS server for user info, and kerberos for authentication (kerbesoe is not important here), the home of each user is on his own computer (this is required since we are using huge huge datasets) also exported via nfs.
The location of homes are exported through NIS auto.home map.
If the user seats on his own computer, autofs mounts his home folder with bind option (not nfs), and if user logins to another computer it uses nfs.
The system worked fine, until the upgrading one the computer to version 6 and autofs-5.0.5-39.el6.x86_64
The problem is that, in the case the mount point is on the same computer it can not mount is any more. The users on that computer are able to use other computers, also other users are able to use that computer.
The hostname is "toros", the original location of files are at "toros:/data/fhach", it tries to mount /home/fhach. Here is the autofs log
Dec 29 21:49:24 toros automount[2433]: sun_mount: parse(sun): mounting root /home, mountpoint fhach, what toros:/data/fhach, fstype nfs4, options
Dec 29 21:49:24 toros automount[2433]: mount_mount: mount(nfs): root=/home name=fhach what=toros:/data/fhach, fstype=nfs4, options=
Dec 29 21:49:24 toros automount[2433]: mount_mount: mount(nfs): nfs options="", nosymlink=0, ro=0
(In reply to comment #0)
>
> The problem is that, in the case the mount point is on the same computer it can
> not mount is any more. The users on that computer are able to use other
> computers, also other users are able to use that computer.
Could it be that the server has been updated as well, perhaps to
use the virtual root feature of NFSv4? In that case the export
path and the mount path are no longer the same.
>
> The hostname is "toros", the original location of files are at
> "toros:/data/fhach", it tries to mount /home/fhach. Here is the autofs log
>
>
> Dec 29 21:49:24 toros automount[2433]: sun_mount: parse(sun): mounting root
> /home, mountpoint fhach, what toros:/data/fhach, fstype nfs4, options
> Dec 29 21:49:24 toros automount[2433]: mount_mount: mount(nfs): root=/home
> name=fhach what=toros:/data/fhach, fstype=nfs4, options=
> Dec 29 21:49:24 toros automount[2433]: mount_mount: mount(nfs): nfs options="",
> nosymlink=0, ro=0
Can you provide the whole debug log, from autofs start to problem
occurrence please.
Ian
Only this client has been updated, the server is still running version 5
As I mentioned everything else works fine, except the case bind mount is needed.
I have attached a log, hope it is fine, I added "-d" to the options and filtered message log by pid.
I just solved the issue, there is a record in /etc/hosts mapping hostname to local ipv6 address, removing that line fixed.
I guess the bug can be closed
(In reply to comment #5)
> I just solved the issue, there is a record in /etc/hosts mapping hostname to
> local ipv6 address, removing that line fixed.
>
> I guess the bug can be closed
Ha, ok.
After looking at the log I was puzzled as to why it wasn't
working but then I saw this comment.
Ian