[PATCH] nested mounts with loop

[PATCH] nested mounts with loop

[Matthias Koenig]

Hi,

we noticed a problem concerning loop mounts on locations that 
have to be mounted before. E.g. consider the following situation,
a NFS server exporting a cd image, which we want to loop mount
locally to get access to the content:

auto.master:
/cdimage        auto.cdimage
/cdcontent      auto.cdcontent

auto.cdimage:
foo             nfsserver:/cdimage/foo.img

auto.cdcontent:
foo             -fstype=auto,loop       :/cdimage/foo/foo.img

The access to /cdcontent/foo will fail, when /cdimage/foo is not 
mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
in this case.
The patch below fixes this problem.

Matthias

Index: autofs-git20070924/daemon/spawn.c
===================================================================
--- autofs-git20070924.orig/daemon/spawn.c
+++ autofs-git20070924/daemon/spawn.c
@@ -293,6 +293,13 @@ int spawn_mount(logger *log, ...)
 	while ((*p++ = va_arg(arg, char *)));
 	va_end(arg);
 
+#ifndef ENABLE_MOUNT_LOCKING
+	/* validate loop mounts as they could be on some location to be
+	 * mounted first */
+	if (!strcmp(argv[4], "-o") && strstr(argv[5], "loop"))
+		options = SPAWN_OPT_ACCESS;
+#endif
+
 	while (retries--) {
 		ret = do_spawn(log, options, prog, (const char **) argv);
 		if (ret & MTAB_NOTUPDATED)

Re: [PATCH] nested mounts with loop

[Ian Kent]

On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
> Hi,
> 
> we noticed a problem concerning loop mounts on locations that 
> have to be mounted before. E.g. consider the following situation,
> a NFS server exporting a cd image, which we want to loop mount
> locally to get access to the content:
> 
> auto.master:
> /cdimage        auto.cdimage
> /cdcontent      auto.cdcontent
> 
> auto.cdimage:
> foo             nfsserver:/cdimage/foo.img
> 
> auto.cdcontent:
> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
> 
> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
> in this case.
> The patch below fixes this problem.

I can't remember now.
I wonder why I don't always call access?
I must have had a reason, let me think about it for a while.

Thanks for the patch.
Ian

Re: [PATCH] nested mounts with loop

[Matthias Koenig]

Ian Kent <raven@themaw.net> writes:

> On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
>> Hi,
>> 
>> we noticed a problem concerning loop mounts on locations that 
>> have to be mounted before. E.g. consider the following situation,
>> a NFS server exporting a cd image, which we want to loop mount
>> locally to get access to the content:
>> 
>> auto.master:
>> /cdimage        auto.cdimage
>> /cdcontent      auto.cdcontent
>> 
>> auto.cdimage:
>> foo             nfsserver:/cdimage/foo.img
>> 
>> auto.cdcontent:
>> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
>> 
>> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
>> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
>> in this case.
>> The patch below fixes this problem.
>
> I can't remember now.
> I wonder why I don't always call access?
> I must have had a reason, let me think about it for a while.

Yes, I first tried to set SPAWN_OPT_ACCESS as default, but this did
not work and had the negative effect, that NFS mounts could not
be mounted anymore, because an access() has been done on the
NFS location description "nfsserver:/cdimage", which then fails.

Matthias

Re: [PATCH] nested mounts with loop

[Ian Kent]

On Wed, 2007-09-26 at 17:32 +0200, Matthias Koenig wrote:
> Ian Kent <raven@themaw.net> writes:
> 
> > On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
> >> Hi,
> >> 
> >> we noticed a problem concerning loop mounts on locations that 
> >> have to be mounted before. E.g. consider the following situation,
> >> a NFS server exporting a cd image, which we want to loop mount
> >> locally to get access to the content:
> >> 
> >> auto.master:
> >> /cdimage        auto.cdimage
> >> /cdcontent      auto.cdcontent
> >> 
> >> auto.cdimage:
> >> foo             nfsserver:/cdimage/foo.img
> >> 
> >> auto.cdcontent:
> >> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
> >> 
> >> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
> >> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
> >> in this case.
> >> The patch below fixes this problem.
> >
> > I can't remember now.
> > I wonder why I don't always call access?
> > I must have had a reason, let me think about it for a while.
> 
> Yes, I first tried to set SPAWN_OPT_ACCESS as default, but this did
> not work and had the negative effect, that NFS mounts could not
> be mounted anymore, because an access() has been done on the
> NFS location description "nfsserver:/cdimage", which then fails.

Of course, I'll go with you're patch.
Thanks
Ian

Re: [PATCH] nested mounts with loop

[Jeff Moyer]

Ian Kent <raven@themaw.net> writes:

> On Wed, 2007-09-26 at 17:32 +0200, Matthias Koenig wrote:
>> Ian Kent <raven@themaw.net> writes:
>> 
>> > On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
>> >> Hi,
>> >> 
>> >> we noticed a problem concerning loop mounts on locations that 
>> >> have to be mounted before. E.g. consider the following situation,
>> >> a NFS server exporting a cd image, which we want to loop mount
>> >> locally to get access to the content:
>> >> 
>> >> auto.master:
>> >> /cdimage        auto.cdimage
>> >> /cdcontent      auto.cdcontent
>> >> 
>> >> auto.cdimage:
>> >> foo             nfsserver:/cdimage/foo.img
>> >> 
>> >> auto.cdcontent:
>> >> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
>> >> 
>> >> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
>> >> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
>> >> in this case.
>> >> The patch below fixes this problem.
>> >
>> > I can't remember now.
>> > I wonder why I don't always call access?
>> > I must have had a reason, let me think about it for a while.
>> 
>> Yes, I first tried to set SPAWN_OPT_ACCESS as default, but this did
>> not work and had the negative effect, that NFS mounts could not
>> be mounted anymore, because an access() has been done on the
>> NFS location description "nfsserver:/cdimage", which then fails.
>
> Of course, I'll go with you're patch.

Are you sure the argument positions will be the same for all of the
mount modules?  Is this really the best way to fix this?

-Jeff

Re: [PATCH] nested mounts with loop

[Ian Kent]

On Wed, 2007-09-26 at 12:02 -0400, Jeff Moyer wrote:
> Ian Kent <raven@themaw.net> writes:
> 
> > On Wed, 2007-09-26 at 17:32 +0200, Matthias Koenig wrote:
> >> Ian Kent <raven@themaw.net> writes:
> >> 
> >> > On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
> >> >> Hi,
> >> >> 
> >> >> we noticed a problem concerning loop mounts on locations that 
> >> >> have to be mounted before. E.g. consider the following situation,
> >> >> a NFS server exporting a cd image, which we want to loop mount
> >> >> locally to get access to the content:
> >> >> 
> >> >> auto.master:
> >> >> /cdimage        auto.cdimage
> >> >> /cdcontent      auto.cdcontent
> >> >> 
> >> >> auto.cdimage:
> >> >> foo             nfsserver:/cdimage/foo.img
> >> >> 
> >> >> auto.cdcontent:
> >> >> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
> >> >> 
> >> >> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
> >> >> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
> >> >> in this case.
> >> >> The patch below fixes this problem.
> >> >
> >> > I can't remember now.
> >> > I wonder why I don't always call access?
> >> > I must have had a reason, let me think about it for a while.
> >> 
> >> Yes, I first tried to set SPAWN_OPT_ACCESS as default, but this did
> >> not work and had the negative effect, that NFS mounts could not
> >> be mounted anymore, because an access() has been done on the
> >> NFS location description "nfsserver:/cdimage", which then fails.
> >
> > Of course, I'll go with you're patch.
> 
> Are you sure the argument positions will be the same for all of the
> mount modules?  Is this really the best way to fix this?

Yes, it's possible that the "-o" could end up in a different position if
the code is modified at some later time without thinking.

The SPAWN_OPT_ACCESS mechanism turned out to be the only way to deal
with this case. I spent a fair while trying to work out another way to
do it but couldn't think of any. People had been using this method for
quite a long time in personal patches.

Ian

Re: [PATCH] nested mounts with loop

[Matthias Koenig]

Ian Kent <raven@themaw.net> writes:

> On Wed, 2007-09-26 at 12:02 -0400, Jeff Moyer wrote:
>> Ian Kent <raven@themaw.net> writes:
>> 
>> > On Wed, 2007-09-26 at 17:32 +0200, Matthias Koenig wrote:
>> >> Ian Kent <raven@themaw.net> writes:
>> >> 
>> >> > On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
>> >> >> Hi,
>> >> >> 
>> >> >> we noticed a problem concerning loop mounts on locations that 
>> >> >> have to be mounted before. E.g. consider the following situation,
>> >> >> a NFS server exporting a cd image, which we want to loop mount
>> >> >> locally to get access to the content:
>> >> >> 
>> >> >> auto.master:
>> >> >> /cdimage        auto.cdimage
>> >> >> /cdcontent      auto.cdcontent
>> >> >> 
>> >> >> auto.cdimage:
>> >> >> foo             nfsserver:/cdimage/foo.img
>> >> >> 
>> >> >> auto.cdcontent:
>> >> >> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
>> >> >> 
>> >> >> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
>> >> >> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
>> >> >> in this case.
>> >> >> The patch below fixes this problem.
>> >> >
>> >> > I can't remember now.
>> >> > I wonder why I don't always call access?
>> >> > I must have had a reason, let me think about it for a while.
>> >> 
>> >> Yes, I first tried to set SPAWN_OPT_ACCESS as default, but this did
>> >> not work and had the negative effect, that NFS mounts could not
>> >> be mounted anymore, because an access() has been done on the
>> >> NFS location description "nfsserver:/cdimage", which then fails.
>> >
>> > Of course, I'll go with you're patch.
>> 
>> Are you sure the argument positions will be the same for all of the
>> mount modules?  Is this really the best way to fix this?
>
> Yes, it's possible that the "-o" could end up in a different position if
> the code is modified at some later time without thinking.

Maybe it is better to iterate over the options?

Matthias

Index: autofs-git20070924/daemon/spawn.c
===================================================================
--- autofs-git20070924.orig/daemon/spawn.c
+++ autofs-git20070924/daemon/spawn.c
@@ -293,6 +293,14 @@ int spawn_mount(logger *log, ...)
        while ((*p++ = va_arg(arg, char *)));
        va_end(arg);
 
+#ifndef ENABLE_MOUNT_LOCKING
+       /* validate loop mounts as they could be on some location to be
+        * mounted first */
+       for (p = argv; *(p+1); p++)
+               if (!strcmp(*p, "-o") && strstr(*(p+1), "loop"))
+                       options = SPAWN_OPT_ACCESS;
+#endif
+
        while (retries--) {
                ret = do_spawn(log, options, prog, (const char **) argv);
                if (ret & MTAB_NOTUPDATED)

Re: [PATCH] nested mounts with loop

[Ian Kent]

On Tue, 2007-10-02 at 11:37 +0200, Matthias Koenig wrote:
> Ian Kent <raven@themaw.net> writes:
> 
> > On Wed, 2007-09-26 at 12:02 -0400, Jeff Moyer wrote:
> >> Ian Kent <raven@themaw.net> writes:
> >> 
> >> > On Wed, 2007-09-26 at 17:32 +0200, Matthias Koenig wrote:
> >> >> Ian Kent <raven@themaw.net> writes:
> >> >> 
> >> >> > On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
> >> >> >> Hi,
> >> >> >> 
> >> >> >> we noticed a problem concerning loop mounts on locations that 
> >> >> >> have to be mounted before. E.g. consider the following situation,
> >> >> >> a NFS server exporting a cd image, which we want to loop mount
> >> >> >> locally to get access to the content:
> >> >> >> 
> >> >> >> auto.master:
> >> >> >> /cdimage        auto.cdimage
> >> >> >> /cdcontent      auto.cdcontent
> >> >> >> 
> >> >> >> auto.cdimage:
> >> >> >> foo             nfsserver:/cdimage/foo.img
> >> >> >> 
> >> >> >> auto.cdcontent:
> >> >> >> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
> >> >> >> 
> >> >> >> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
> >> >> >> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
> >> >> >> in this case.
> >> >> >> The patch below fixes this problem.
> >> >> >
> >> >> > I can't remember now.
> >> >> > I wonder why I don't always call access?
> >> >> > I must have had a reason, let me think about it for a while.
> >> >> 
> >> >> Yes, I first tried to set SPAWN_OPT_ACCESS as default, but this did
> >> >> not work and had the negative effect, that NFS mounts could not
> >> >> be mounted anymore, because an access() has been done on the
> >> >> NFS location description "nfsserver:/cdimage", which then fails.
> >> >
> >> > Of course, I'll go with you're patch.
> >> 
> >> Are you sure the argument positions will be the same for all of the
> >> mount modules?  Is this really the best way to fix this?
> >
> > Yes, it's possible that the "-o" could end up in a different position if
> > the code is modified at some later time without thinking.
> 
> Maybe it is better to iterate over the options?

Yep, I've just done something similar myself.

Ian

Re: [PATCH] nested mounts with loop

[Ian Kent]

On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
> Hi,
> 
> we noticed a problem concerning loop mounts on locations that 
> have to be mounted before. E.g. consider the following situation,
> a NFS server exporting a cd image, which we want to loop mount
> locally to get access to the content:
> 
> auto.master:
> /cdimage        auto.cdimage
> /cdcontent      auto.cdcontent
> 
> auto.cdimage:
> foo             nfsserver:/cdimage/foo.img
> 
> auto.cdcontent:
> foo             -fstype=auto,loop       :/cdimage/foo/foo.img

Just trying to test this out and it seem that this should
read :/cdimage/foo.

Correct?

Ian

Re: [PATCH] nested mounts with loop

[Ian Kent]

On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
> Hi,
> 
> we noticed a problem concerning loop mounts on locations that 
> have to be mounted before. E.g. consider the following situation,
> a NFS server exporting a cd image, which we want to loop mount
> locally to get access to the content:
> 
> auto.master:
> /cdimage        auto.cdimage
> /cdcontent      auto.cdcontent
> 
> auto.cdimage:
> foo             nfsserver:/cdimage/foo.img
> 
> auto.cdcontent:
> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
> 
> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
> in this case.

This test case seems broken to me.
Can you check you've described this correctly please.
Maybe even try this exact setup yourself.

Even if the maps were correct the procedure you describe wouldn't call
spawn_mount first, it would call spawn_bind_mount, which would then
trigger the mount through the access call.

Ian

Re: [PATCH] nested mounts with loop

[Matthias Koenig]

Ian Kent <raven@themaw.net> writes:

> On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
>> Hi,
>> 
>> we noticed a problem concerning loop mounts on locations that 
>> have to be mounted before. E.g. consider the following situation,
>> a NFS server exporting a cd image, which we want to loop mount
>> locally to get access to the content:
>> 
>> auto.master:
>> /cdimage        auto.cdimage
>> /cdcontent      auto.cdcontent
>> 
>> auto.cdimage:
>> foo             nfsserver:/cdimage/foo.img
>> 

Yes, sorry. It is nfsserver:/cdimage/foo of course.
I invented this testcase in place, because the original setup
was less readable.

>> auto.cdcontent:
>> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
>> 
>> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
>> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
>> in this case.
>
> This test case seems broken to me.
> Can you check you've described this correctly please.
> Maybe even try this exact setup yourself.

I checked this again and adapt it to the testcase described here.
auto.master remaining as shown above.

giuliani:/ # cat /etc/auto.cdimage 
foo     dist:/dist/install/openSUSE-10.3-GM/

giuliani:/ # cat /etc/auto.cdcontent 
foo -fstype=auto,loop,ro :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso

> Even if the maps were correct the procedure you describe wouldn't call
> spawn_mount first, it would call spawn_bind_mount, which would then
> trigger the mount through the access call.

Hmm, with the above setup, I am only able to access the content after I
have triggered the mount of the image separately.

giuliani:/ # ls /cdcontent/foo
ls: cannot open directory /cdcontent/foo: No such file or directory
giuliani:/ # ls /cdimage/foo/
[...]
giuliani:/ # ls /cdcontent/foo
ARCHIVES.gz     dosutils                          INDEX.gz
[...]

Here is the log of the failure:
Oct  8 14:25:17 giuliani automount[16597]: lookup_mount: lookup(file): looking up foo
Oct  8 14:25:17 giuliani automount[16597]: lookup_mount: lookup(file): foo -> -fstype=auto,loop,ro :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): expanded entry: -fstype=auto,loop,ro :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): gathered options: fstype=auto,loop,ro
Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): dequote(":/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso") -> :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): core of entry: options=fstype=auto,loop,ro, loc=:/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
Oct  8 14:25:17 giuliani automount[16597]: sun_mount: parse(sun): mounting root /cdcontent, mountpoint foo, what /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso, fstype auto, options loop,ro
Oct  8 14:25:17 giuliani automount[16597]: open_mount: (mount):cannot open mount module auto (/usr/lib/autofs/mount_auto.so: cannot open shared object file: No such file or directory)
Oct  8 14:25:17 giuliani automount[16597]: do_mount: /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso /cdcontent/foo type auto options loop,ro using module generic
Oct  8 14:25:17 giuliani automount[16597]: mount_mount: mount(generic): calling mkdir_path /cdcontent/foo
Oct  8 14:25:17 giuliani automount[16597]: mount_mount: mount(generic): calling mount -t auto -s -o loop,ro /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso /cdcontent/foo
Oct  8 14:25:17 giuliani automount[16597]: >> /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso: No such file or directory
Oct  8 14:25:17 giuliani automount[16597]: mount(generic): failed to mount /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso (type auto) on /cdcontent/foo
Oct  8 14:25:17 giuliani automount[16597]: send_fail: token = 61
Oct  8 14:25:17 giuliani automount[16597]: failed to mount /cdcontent/foo


Thanks,
Matthias

Re: [PATCH] nested mounts with loop

[Ian Kent]

On Mon, 2007-10-08 at 14:28 +0200, Matthias Koenig wrote:
> Ian Kent <raven@themaw.net> writes:
> 
> > On Tue, 2007-09-25 at 18:21 +0200, Matthias Koenig wrote:
> >> Hi,
> >> 
> >> we noticed a problem concerning loop mounts on locations that 
> >> have to be mounted before. E.g. consider the following situation,
> >> a NFS server exporting a cd image, which we want to loop mount
> >> locally to get access to the content:
> >> 
> >> auto.master:
> >> /cdimage        auto.cdimage
> >> /cdcontent      auto.cdcontent
> >> 
> >> auto.cdimage:
> >> foo             nfsserver:/cdimage/foo.img
> >> 
> 
> Yes, sorry. It is nfsserver:/cdimage/foo of course.
> I invented this testcase in place, because the original setup
> was less readable.
> 
> >> auto.cdcontent:
> >> foo             -fstype=auto,loop       :/cdimage/foo/foo.img
> >> 
> >> The access to /cdcontent/foo will fail, when /cdimage/foo is not 
> >> mounted before, because spawn_mount does not use SPAWN_OPT_ACCESS
> >> in this case.
> >
> > This test case seems broken to me.
> > Can you check you've described this correctly please.
> > Maybe even try this exact setup yourself.
> 
> I checked this again and adapt it to the testcase described here.
> auto.master remaining as shown above.
> 
> giuliani:/ # cat /etc/auto.cdimage 
> foo     dist:/dist/install/openSUSE-10.3-GM/
> 
> giuliani:/ # cat /etc/auto.cdcontent 
> foo -fstype=auto,loop,ro :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> 
> > Even if the maps were correct the procedure you describe wouldn't call
> > spawn_mount first, it would call spawn_bind_mount, which would then
> > trigger the mount through the access call.
> 
> Hmm, with the above setup, I am only able to access the content after I
> have triggered the mount of the image separately.

Mmm .. but my comment above assumes you're autofs build uses the
configure option --disable-mount-locking.

Is that correct?

If not then this can't be done because the locking will cause a
deadlock, consequently the code that calls access isn't compiled in and
recursive mounts aren't possible.

> 
> giuliani:/ # ls /cdcontent/foo
> ls: cannot open directory /cdcontent/foo: No such file or directory
> giuliani:/ # ls /cdimage/foo/
> [...]
> giuliani:/ # ls /cdcontent/foo
> ARCHIVES.gz     dosutils                          INDEX.gz
> [...]
> 
> Here is the log of the failure:
> Oct  8 14:25:17 giuliani automount[16597]: lookup_mount: lookup(file): looking up foo
> Oct  8 14:25:17 giuliani automount[16597]: lookup_mount: lookup(file): foo -> -fstype=auto,loop,ro :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): expanded entry: -fstype=auto,loop,ro :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): gathered options: fstype=auto,loop,ro
> Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): dequote(":/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso") -> :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): core of entry: options=fstype=auto,loop,ro, loc=:/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> Oct  8 14:25:17 giuliani automount[16597]: sun_mount: parse(sun): mounting root /cdcontent, mountpoint foo, what /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso, fstype auto, options loop,ro
> Oct  8 14:25:17 giuliani automount[16597]: open_mount: (mount):cannot open mount module auto (/usr/lib/autofs/mount_auto.so: cannot open shared object file: No such file or directory)
> Oct  8 14:25:17 giuliani automount[16597]: do_mount: /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso /cdcontent/foo type auto options loop,ro using module generic
> Oct  8 14:25:17 giuliani automount[16597]: mount_mount: mount(generic): calling mkdir_path /cdcontent/foo
> Oct  8 14:25:17 giuliani automount[16597]: mount_mount: mount(generic): calling mount -t auto -s -o loop,ro /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso /cdcontent/foo
> Oct  8 14:25:17 giuliani automount[16597]: >> /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso: No such file or directory
> Oct  8 14:25:17 giuliani automount[16597]: mount(generic): failed to mount /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso (type auto) on /cdcontent/foo
> Oct  8 14:25:17 giuliani automount[16597]: send_fail: token = 61
> Oct  8 14:25:17 giuliani automount[16597]: failed to mount /cdcontent/foo
> 
> 
> Thanks,
> Matthias

Re: [PATCH] nested mounts with loop

[Matthias Koenig]

Ian Kent <raven@themaw.net> writes:

> Mmm .. but my comment above assumes you're autofs build uses the
> configure option --disable-mount-locking.
>
> Is that correct?
>
> If not then this can't be done because the locking will cause a
> deadlock, consequently the code that calls access isn't compiled in and
> recursive mounts aren't possible.

Yes, the build is with the --disable-mount-locking option.

Thanks,
Matthias

Re: [PATCH] nested mounts with loop

[Ian Kent]

On Mon, 2007-10-08 at 14:28 +0200, Matthias Koenig wrote:
> Ian Kent <raven@themaw.net> writes:
> 
> Hmm, with the above setup, I am only able to access the content after I
> have triggered the mount of the image separately.
> 
> giuliani:/ # ls /cdcontent/foo
> ls: cannot open directory /cdcontent/foo: No such file or directory
> giuliani:/ # ls /cdimage/foo/
> [...]
> giuliani:/ # ls /cdcontent/foo
> ARCHIVES.gz     dosutils                          INDEX.gz
> [...]

Yep, reproduced and verified our approach fixes the problem.

> 
> Here is the log of the failure:
> Oct  8 14:25:17 giuliani automount[16597]: lookup_mount: lookup(file): looking up foo
> Oct  8 14:25:17 giuliani automount[16597]: lookup_mount: lookup(file): foo -> -fstype=auto,loop,ro :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): expanded entry: -fstype=auto,loop,ro :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): gathered options: fstype=auto,loop,ro
> Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): dequote(":/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso") -> :/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> Oct  8 14:25:17 giuliani automount[16597]: parse_mount: parse(sun): core of entry: options=fstype=auto,loop,ro, loc=:/cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso
> Oct  8 14:25:17 giuliani automount[16597]: sun_mount: parse(sun): mounting root /cdcontent, mountpoint foo, what /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso, fstype auto, options loop,ro
> Oct  8 14:25:17 giuliani automount[16597]: open_mount: (mount):cannot open mount module auto (/usr/lib/autofs/mount_auto.so: cannot open shared object file: No such file or directory)
> Oct  8 14:25:17 giuliani automount[16597]: do_mount: /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso /cdcontent/foo type auto options loop,ro using module generic
> Oct  8 14:25:17 giuliani automount[16597]: mount_mount: mount(generic): calling mkdir_path /cdcontent/foo
> Oct  8 14:25:17 giuliani automount[16597]: mount_mount: mount(generic): calling mount -t auto -s -o loop,ro /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso /cdcontent/foo

Aaha .. now I get it!

This type of request calls the generic mount module which, in turn calls
spawn_mount which leads to the problem.

> Oct  8 14:25:17 giuliani automount[16597]: >> /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso: No such file or directory
> Oct  8 14:25:17 giuliani automount[16597]: mount(generic): failed to mount /cdimage/foo/openSUSE-10.3-GM-DVD-i386.iso (type auto) on /cdcontent/foo
> Oct  8 14:25:17 giuliani automount[16597]: send_fail: token = 61
> Oct  8 14:25:17 giuliani automount[16597]: failed to mount /cdcontent/foo

I will need to do more testing before committing the change but it
should be fine.

Thanks
Ian