rgm@thorin.hw.stratus.com (03/21/90)
We are having problems with the automount program. We are running SunOS
4.0.3 and the problem shows up something like this:
thorin% pwd
pwd: getwd: can't open ..
and:
thorin% df .
Filesystem kbytes used avail capacity Mounted on
Could not find mount point for .
but you can still work in the directory and list it etc.
What seems to happen is that when someone goes into a auto-mounted
directory and works there for a while this just seems to happen after a
while. The way to recover from it is you can just change directories back
to where you were and continue working, but this is kind of a pain, and is
causing some of our applications to break.
I have not been able to reproduce this on a steady basis which makes it
real hard to trouble shoot. I have seen this happen on 3/80's, 4/60's,
4/280's.
Has anyone else seen this problem? Does anyone know if there is a fix for
something like this?
Richard Meitzler, Stratus Computer, Marlboro, MA
rgm@thorin.hw.stratus.com -or- Richard_Meitzler@es.stratus.com
uunet!lectroid.sw.stratus.com!thorin.hw.stratus.com!rgmpearlman@rand.org (Laura Pearlman) (03/24/90)
In article <5959@brazos.Rice.edu> rgm@thorin.hw.stratus.com writes: >X-Sun-Spots-Digest: Volume 9, Issue 87, message 12 > >We are having problems with the automount program. We are running SunOS >4.0.3 and the problem shows up something like this: > > thorin% pwd > pwd: getwd: can't open .. > >and: > > thorin% df . > Filesystem kbytes used avail capacity Mounted on > Could not find mount point for . > >but you can still work in the directory and list it etc. Getwd and df will fail like that if you mount a directory on top of itself, and you're not in the top-level mount point directory. In other words, if you do: mount foo:/bar /mnt cd /mnt/blech # edit out the "foo:/bar ... /mnt" entry in /etc/mtab mount foo:/bar /mnt pwd df . then you'll see the same behavior you described above. This is because whenever an nfs filesystem is mounted, it's assigned a dev number that is different from the dev numbers of any other filesystems mounted at the time. The problem in the example above is that the dev number for "." (the first dev number assigned) is now different from from the dev number for "/mnt/blech" (the second dev number assigned). I don't have any idea why automount would behave this way, though. My only guess is that somehow automount has attempted to unmount a filesystem and unlinked its symlink without realizing that the unmount failed, and then remounted the filesystem again later because the symlink was gone. -- Laura pearlman@rand.org