I tried to subscribe to the autofs list, but majordomo isn't replying to
me! I think this is a problem in the automount daemon rather than the
kernel autofs code itself.
I'm trying to automount our home dirs as
/homes/$USERNAME
which should bind mount to
:/home/$SERVER/$HOMENAME/$USERNAME
which should bind mount to
:/home/$SERVER/$VOLUME/$PATH/$USERNAME
which (phew!) will be an NFS mount to
$SERVER:/$VOLUME/$PATH/$USERNAME
The idea is that:
(1) `/bin/pwd` = "/homes/$USERNAME"
(2) when you run "quota" it'll only report for $SERVER:/$VOLUME
Now.. this all works perfectly if before looking at /homes/$USERNAME you
look at firstly /home/$SERVER/$VOLUME/$PATH/$USERNAME and then secondly
/home/$SERVER/$HOMENAME/$USERNAME, because the bind mounts have something
to bind to. Of course you shouldn't need to know the middle bits, but you
could look them up. Currently the binds mount fail and automount drops in
symlinks; this satisfies (2) above, but unfortunately not (1).
I hope someone can make sense of this. Is it different in autofs4?
Matt
Followup to: <[email protected]>
By author: Matt Bernstein <mb/[email protected]>
In newsgroup: linux.dev.kernel
>
> I tried to subscribe to the autofs list, but majordomo isn't replying to
> me! I think this is a problem in the automount daemon rather than the
> kernel autofs code itself.
>
> I'm trying to automount our home dirs as
> /homes/$USERNAME
> which should bind mount to
> :/home/$SERVER/$HOMENAME/$USERNAME
> which should bind mount to
> :/home/$SERVER/$VOLUME/$PATH/$USERNAME
> which (phew!) will be an NFS mount to
> $SERVER:/$VOLUME/$PATH/$USERNAME
>
> The idea is that:
> (1) `/bin/pwd` = "/homes/$USERNAME"
> (2) when you run "quota" it'll only report for $SERVER:/$VOLUME
>
> Now.. this all works perfectly if before looking at /homes/$USERNAME you
> look at firstly /home/$SERVER/$VOLUME/$PATH/$USERNAME and then secondly
> /home/$SERVER/$HOMENAME/$USERNAME, because the bind mounts have something
> to bind to. Of course you shouldn't need to know the middle bits, but you
> could look them up. Currently the binds mount fail and automount drops in
> symlinks; this satisfies (2) above, but unfortunately not (1).
>
> I hope someone can make sense of this. Is it different in autofs4?
>
This is unfortunately nearly impossible to solve. It's a known bug,
but it's questionable if anything can be done about it.
For right now, autofs cannot bind-mount to a mount from the same
automount point (the problem is with the double-use of /home/$SERVER
in your case.)
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: "H. Peter Anvin" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Followup to: <[email protected]>
> By author: Matt Bernstein <mb/[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > I tried to subscribe to the autofs list, but majordomo isn't replying to
> > me! I think this is a problem in the automount daemon rather than the
> > kernel autofs code itself.
> >
> > I'm trying to automount our home dirs as
> > /homes/$USERNAME
> > which should bind mount to
> > :/home/$SERVER/$HOMENAME/$USERNAME
> > which should bind mount to
> > :/home/$SERVER/$VOLUME/$PATH/$USERNAME
> > which (phew!) will be an NFS mount to
> > $SERVER:/$VOLUME/$PATH/$USERNAME
> >
> > The idea is that:
> > (1) `/bin/pwd` = "/homes/$USERNAME"
> > (2) when you run "quota" it'll only report for $SERVER:/$VOLUME
> >
> > Now.. this all works perfectly if before looking at /homes/$USERNAME you
> > look at firstly /home/$SERVER/$VOLUME/$PATH/$USERNAME and then secondly
> > /home/$SERVER/$HOMENAME/$USERNAME, because the bind mounts have something
> > to bind to. Of course you shouldn't need to know the middle bits, but you
> > could look them up. Currently the binds mount fail and automount drops in
> > symlinks; this satisfies (2) above, but unfortunately not (1).
> >
> > I hope someone can make sense of this. Is it different in autofs4?
> >
>
> This is unfortunately nearly impossible to solve. It's a known bug,
> but it's questionable if anything can be done about it.
>
> For right now, autofs cannot bind-mount to a mount from the same
> automount point (the problem is with the double-use of /home/$SERVER
> in your case.)
>
Actually, if you're using autofs v3, which it sounds like you're
doing, it's even more broken, since autofs v3 doesn't support
multilevel mounts.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Tue, Aug 20, 2002 at 02:35:26PM -0700, H. Peter Anvin wrote:
> Actually, if you're using autofs v3, which it sounds like you're
> doing, it's even more broken, since autofs v3 doesn't support
> multilevel mounts.
Is there an autofs v4 daemon that's actually released? The only thing I
see is code that's over a year old in /pub/linux/daemons/autofs/testing-v4/
on kernel.org. If pre10 is okay, it should be released (at least that
would explain why we're still shipping v3).
-ben
--
"You will be reincarnated as a toad; and you will be much happier."
Benjamin LaHaise wrote:
> On Tue, Aug 20, 2002 at 02:35:26PM -0700, H. Peter Anvin wrote:
>
>>Actually, if you're using autofs v3, which it sounds like you're
>>doing, it's even more broken, since autofs v3 doesn't support
>>multilevel mounts.
>
>
> Is there an autofs v4 daemon that's actually released? The only thing I
> see is code that's over a year old in /pub/linux/daemons/autofs/testing-v4/
> on kernel.org. If pre10 is okay, it should be released (at least that
> would explain why we're still shipping v3).
>
The problem is that autofs v4 is completely unmaintained at the moment.
-hpa
On Tue, Aug 20, 2002 at 03:18:33PM -0700, H. Peter Anvin wrote:
> The problem is that autofs v4 is completely unmaintained at the moment.
Is there a todo list or known set of outstanding problems with it?
-ben
--
"You will be reincarnated as a toad; and you will be much happier."
Benjamin LaHaise wrote:
> On Tue, Aug 20, 2002 at 03:18:33PM -0700, H. Peter Anvin wrote:
>
>>The problem is that autofs v4 is completely unmaintained at the moment.
>
>
> Is there a todo list or known set of outstanding problems with it?
>
Not that I know of. I don't believe the code has been analyzed for
races; in fact, it seems to me that there are inherent races in mount
point deconstruction.
-hpa
>>>>> "Benjamin" == Benjamin LaHaise <[email protected]> writes:
Benjamin> Is there an autofs v4 daemon that's actually released? The
Benjamin> only thing I see is code that's over a year old in
Benjamin> /pub/linux/daemons/autofs/testing-v4/ on kernel.org. If
Benjamin> pre10 is okay, it should be released (at least that would
Benjamin> explain why we're still shipping v3).
Well, HPA says that pre10 has some serious problems, but it was the
only version I could get to work with our Solaris NIS environment and
out NetApps reliably. I'd release the darn thing and let people send
in patches as needed.
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
[email protected] - http://www.lucent.com - 978-399-0479
[email protected] wrote:
>>>>>>"Benjamin" == Benjamin LaHaise <[email protected]> writes:
>>>>>
>
> Benjamin> Is there an autofs v4 daemon that's actually released? The
> Benjamin> only thing I see is code that's over a year old in
> Benjamin> /pub/linux/daemons/autofs/testing-v4/ on kernel.org. If
> Benjamin> pre10 is okay, it should be released (at least that would
> Benjamin> explain why we're still shipping v3).
>
> Well, HPA says that pre10 has some serious problems, but it was the
> only version I could get to work with our Solaris NIS environment and
> out NetApps reliably. I'd release the darn thing and let people send
> in patches as needed.
>
I said I *think* it is racy, mostly because noone has ever bothered
showing it to the contrary, and because I have failed to see how it
*couldn't* be.
-hpa