On 04/27/2010 02:32 PM, Agile Aspect wrote: > On Tue, Apr 27, 2010 at 1:51 PM, Trevor Cooper<tcooper at ucsd.edu> wrote: >> I'm having a problem with automount (autofs) from a server running >> CentOS 5.4 to clients (example is CentOS 5.4). Client pulls automount >> maps from NIS. THIS particular server is also used for login so it is >> NIS bound as well (other servers are NOT). >> > > I inherited a similar problem but different environment, namely, SUSE, > CentOS 4, and CentOS 5 - with SUSE the primary NIS server. > > In the end, in order to get everyone to play nicely, I ended up using > the following in the /etc/auto.master file > > #+auto.master > /home yp:auto.home > /usr/grid yp:auto.grid > > etc. > Since your suggestion for changing /etc/auto.master referenced #+auto.master I assumed you were suggesting the change for a NFS client. Trying to solve the issue this way doesn't seem to work. On the NFS Server (also a NIS bound NFS client) I made the suggested changes and reloaded the automount maps. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here is the directory tree on of the exported filesystem(s) LOCAL to the NFS server... $ tree -L 3 /mdkm1 /mdkm1 |-- 1 | |-- kmdev | | `-- projects | `-- lost+found [error opening dir] . . . |-- 10 | |-- kmdev | | `-- projects | `-- lost+found [error opening dir] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here is the same command looking at the NFS automounted directories... [tcooper-local at rilkm01 ~]$ tree -L 3 /storage/mdkm1 /storage/mdkm1 |-- 1 | |-- kmdev | | `-- projects | `-- lost+found [error opening dir] . . . |-- 10 [error opening dir] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Still NO access to /storage/mdkm1/10 from a client and in THIS example the client IS the NFS server talking to itself. The filesystem is ext3 on an VG/LV from a RAID5 storage enclosure. The filesystem has been umounted, fsck'd and remounted. ALL other VG/LV's from the same enclosure (ie. /mdkm[1-9]) are fine. Still scratching the head on this one... Trevor Cooper