0

The issue I am trying to resolve is a bit of a head-scratcher. I say that because the issue is consistently inconsistent and not happening on all of the Ubuntu 16.04 VMs that are hosted in our ESXi environment. I have an NSF export on my FluidFS nas that holds all of my user's home shares. The home share is mounted using autofs and mounts the "home" folder on the NAS at /home on all systems. This issue started to occur after a recent move of our infrastructure from an office space to a data center.

Below is my auto.master file and the map file named auto.blah, based on what I have read about autofs and our current configuration this should and does work, just not on all of our systems. What also adds to the odd functionality of this is there are other NFS mounts that I am mounting with autofs as you will see in the auto.mater and the auto.blah files.

The other NFS mounts are working without issue on all of the 16.04 systems even the ones that are not mounting the /home shares. This leads me to think there is something happening on these systems that are not working correctly and not an issue with the NAS or NFS share exports.

The following info might be helpful as well in troubleshooting this issue. When I moved to the data center we did experience permission issues with the NFS mounts due to our network time being all jacked-up. This was due to the NTP VM that is used for network time was not pulling the correct time data from the pool the ntp service was pulling from. This was fixed and the share permissions issue was resolved. I am not sure if there is any leftover issue from that on the systems that are having issues with the /home share. Just wanted to include that so all the data about the environment has been put out there. I have checked the time on the affected systems, they are not showing any deviation and are correct time zone and time.

Autofs version is 5.1.1-lubuntu3.1

I am not seeing any errors in any logs that might have data pertaining to mounting the NFS exports.

Contents of auto.master file

#
# Sample auto.master file
# This is a 'master' automounter map and it has the following format:
# mount-point [map-type[,format]:]map [options]
# For details of the format look at auto.master(5).
#
#/misc  /etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
#   "nosuid" and "nodev" options unless the "suid" and "dev"
#   options are explicitly given.
#
#/net   -hosts
#
# Include /etc/auto.master.d/*.autofs
# The included files must conform to the format of this file.
#
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master

/-  /etc/auto.blah

/host   /etc/auto.host --timeout 600

/host-fast /etc/auto.fastscratch --timeout 600

Contents of auto.blah file

/home       -hard,tcp,nfsvers=3,timeo=3,retrans=10,rsize=32768,wsize=32768  nas01.blah.local:/Home2/root/&
/cyc    -hard,tcp,nfsvers=3,timeo=3,retrans=10,rsize=32768,wsize=32768  nas01.blah.local:/Cyc/root/cyc/
/space1 -hard,tcp,nfsvers=3,timeo=3,retrans=10,rsize=32768,wsize=32768  nas01.blah.local:/space1/root/space1/
/static1        -hard,tcp,nfsvers=3,timeo=3,retrans=10,rsize=32768,wsize=32768  nas01.blah.local:/static1/root/static1/
/Clueweb -hard,tcp,nfsvers=3,timeo=3,retrans=10,rsize=32768,wsize=32768  nas01.blah.local:/Clueweb/root/Clueweb/
/build  -hard,tcp,nfsvers=3,timeo=3,retrans=10,rsize=32768,wsize=32768  nas01.blah.local:/build/root/build/
/archive -hard,tcp,nfsvers=3,timeo=3,retrans=10,rsize=32768,wsize=32768  nas01.blah.local:/archive/root/archive/

EDIT: Whenever I navigate to the /home share on a system doesn't work properly I am presented with -bash: cd: /home: Too many levels of symbolic links.

I have looked into this error and from what I found it is usually caused by linking to a link. I don't see how this is possible since I am not symlinking a directory to /home.

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
  • Have you tried if the problem also exists with a newer version of Ubuntu? 16.04 is going to be end of life in 5 months, might be a good time to upgrade. – Gerald Schneider Nov 27 '20 at 08:30
  • Deployment of a new system is done using a PXE server that will update and upgrade the OS during the install. – RocketShip09901 Nov 27 '20 at 17:00

0 Answers0