From: Tom Georgoulias <tom.georgoulias@freescale.com>
To: autofs mailing list <autofs@linux.kernel.org>
Subject: mount fails because entry in multi-mount doesn't work
Date: Thu, 13 May 2004 09:26:13 -0500 [thread overview]
Message-ID: <40A38585.4050103@freescale.com> (raw)
Yesterday I ran into an issue where a mount point wasn't working and
tracked it down to one of the submounts. From what I can tell, if one
of the submounts in a multi-mount doesn't work, the entire mount point
won't work. If that is the case, can this behavior be changed?
System:
Sun V20Z running RHEL3 WS AMD64, 2.4.21-15ELsmp (with
kernel-smp-unsupported-2.4.21-15.EL RPM to get autofs4 module) and
autofs-4.1.2-6 from Jeff Moyer.
[root@winston root]# cd /proj/tec/layout/copperhead
-bash: cd: /proj/tec/layout/copperhead: No such file or directory
Checked the messages:
[root@winston root]# tail /var/log/messages
May 12 17:22:47 winston automount[8314]: rm_unwanted:
/proj/tec/layout/maskprep1
May 12 17:22:47 winston automount[8314]: rm_unwanted:
/proj/tec/layout/copperhead
May 12 17:22:47 winston automount[8314]: rm_unwanted: /proj/tec/layout
May 12 17:22:47 winston automount[6941]: attempting to mount entry
/proj/tec/layout
May 12 17:22:47 winston automount[8318]: >> mount:
macduff:/fsys/fs04/maskprep1 failed, reason given by server: Permission
denied
May 12 17:22:47 winston automount[8318]: mount(nfs): nfs: mount failure
macduff:/fsys/fs04/maskprep1 on /proj/tec/layout/maskprep1
May 12 17:22:47 winston automount[8318]: failed to mount /proj/tec/layout
May 12 17:22:47 winston automount[8318]: rm_unwanted:
/proj/tec/layout/maskprep1
May 12 17:22:47 winston automount[8318]: rm_unwanted:
/proj/tec/layout/copperhead
May 12 17:22:47 winston automount[8318]: rm_unwanted: /proj/tec/layout
Noticed how mount failed for /proj/tec/layout/maskprep1, then the whole
/proj/tec/layout mount fails. The mount point it was failing on is
intentionally unshared at the moment, so I'm not surprise it couldn't
make it. Took the entry out of the automount map
layout \
/copperhead eclipse0:/export/layout/copperhead \
/maskprep1 macduff:/fsys/fs04/maskprep1 \
<snip>
refreshed the automount daemon's cache. Mount works now.
[root@winston root]# pkill -HUP -f auto.proj
[root@winston root]# cd /proj/tec/layout/copperhead
[root@winston copperhead]# ls
mpc5554.0l00x mpc5554.0l87p restore
[root@winston copperhead]#
Tom
--
Tom Georgoulias
POPI Classification
[x] General Business Information
[] Freescale Semiconductor Internal Use
[] Freescale Semiconductor Confidential Proprietary
next reply other threads:[~2004-05-13 14:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-13 14:26 Tom Georgoulias [this message]
2004-05-13 15:08 ` mount fails because entry in multi-mount doesn't work raven
2004-05-13 17:59 ` Taylor, ForrestX
2004-05-13 18:32 ` Tom Georgoulias
2004-05-13 19:05 ` Jeff Moyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40A38585.4050103@freescale.com \
--to=tom.georgoulias@freescale.com \
--cc=autofs@linux.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.