Should mount --bind not follow symlinks?

Hi,
My automounted dirs have up till now been symlinks, where
e.g. /opt/perl defaults to automounting /export/opt/perl/LATEST which is a symlink.

This all worked OK until the 2.4(.2) automounter helpfully tries
to mount --bind /export/opt/perl/LATEST /opt/perl

And this errors with "mount: wrong fs type, ..." because it
seems the first arg to mount --bind mustn't be a symlink, resulting in a "No such file" or similar error being returned to the requester.

What is especially confusing is that if this whole thing
was kicked off with say ls /opt/perl/bin, the first attempt returns "No such file or directory", but automount then installs a symlink into /opt, so a second ls attempt works fine.

Is this known about / to be expected? I can't see why
one of automount or mount or the underlying system call shouldn't chase symlinks, but I know I might be missing some reason why I shouldn't be attempting this.

Anthony

Don't mix symlinks with mounts/bindings. Too much PITA and yes, it had been deliberately prohibited. You _really_ don't want to handle the broken symlinks and all the realted fun - race-ridden at extreme and useless.

In automount-like setups you can _replace_ symlinks with bindings. No need to mix them.
Cheers,
Al

No. But I hoped _you_ might :-)

Hmm. My /etc/auto.opt contains

* :/export/opt/&/LATEST

where all the "LATEST"s etc are symlinks. I found it quite an elegant way to maintain different versions: the symlink was de-facto a trivially simple version database.

Does the version state now *have* to be listed in /etc/auto.opt explicitly? That feels a little retrograde.

Perhaps I'm blissfully unaware of all sorts of vile race conditions, but why can't the *automounter* chase the symlinks even if mount shouldn't? Or am I missing a neater solution?

Rgds

Anthony

The automounter could indeed chase those symlinks.

Also, if the automounter creates a symlink in /opt anyway, and the link subsequently works (as you said), then it shouldn't be returning "No such file or directory" the first time.

In other words the latter behaviour looks like a bug in the automounter, and the former is a feature which could be added but isn't needed for your application.

-- Jamie

Okay! Well, the following I think fixes everything for me, as a small tweak to autofs-4.0.0pre9.

Thanks

Anthony

*** modules/mount_bind.c.Orig Sun Mar 25 15:43:27 2001
--- modules/mount_bind.c Mon Mar 26 22:57:10 2001
***************
*** 19,24 ****
--- 19,25 ----
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
+ #include <stdlib.h>
#include <syslog.h>
#include <string.h>
#include <sys/param.h>
***************
*** 71,76 ****
--- 72,84 ----

    char *fullpath;
    int err;
    int i;

+
+ char real[PATH_MAX];
+ if (!realpath(what, real)) {
+ syslog(LOG_NOTICE, MODPREFIX "realpath %s failed: %m", what);
+ return 1;
+ }
+ what = real;

    fullpath = alloca(strlen(root)+name_len+2);
    if ( !fullpath ) {

[email protected] (Alexander Viro) wrote on 12.03.01 in <[email protected]>:

Race? Where? You resolve the symlink once and operate on the result. No need to remember anywhere that it ever was a symlink. If there *can* be a race, this sounds like a serious design bug.

This looks like it *seriously* breaks my current 2.2 setup: I have dirs with sensible names under /Partition, and symlinks to those dirs whose name is the UUID for mount to use. Nothing automount in here. (And of course all those links and directories are completely static and only root- modifiable anyway, this only changes when I repartition.)

MfG Kai