Skip to contentSkip to conversation

nested mounts with loop

PATCH In review Matthias Koenig 3 participants 14 messages Sep 25, 2007 – Oct 10, 2007 Kernel automounter

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 nested mounts with loop

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

daemon/spawn.c +7 -0
Index: 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)
maintainer
#1 lore raw
Quoted 14 lines · 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

Quoted 7 lines

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

#2 lore raw
Quoted 18 lines · Ian Kent
Quoted 17 lines · 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

Quoted 8 lines
Quoted 4 lines

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

maintainer
#3 lore raw
Quoted 25 lines · Matthias Koenig
Quoted 23 lines · Ian Kent
Quoted 21 lines · 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.

Quoted 8 lines
Quoted 3 lines

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

#4 lore raw
Quoted 30 lines · Ian Kent
Quoted 29 lines · Matthias Koenig
Quoted 26 lines · Ian Kent
Quoted 14 lines · 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

Quoted 7 lines

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.

Quoted 6 lines
Quoted 4 lines

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

maintainer
#5 lore raw
Quoted 37 lines · Jeff Moyer
Quoted 35 lines · Ian Kent
Quoted 33 lines · Matthias Koenig
Quoted 18 lines · Ian Kent
Quoted 17 lines · 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

Quoted 8 lines
Quoted 4 lines

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.

Quoted 4 lines
Quoted 1 line

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

#6 lore raw
Quoted 38 lines · Ian Kent
Quoted 37 lines · Jeff Moyer
Quoted 35 lines · Ian Kent
Quoted 33 lines · Matthias Koenig
Quoted 18 lines · Ian Kent
Quoted 17 lines · 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

Quoted 8 lines
Quoted 4 lines

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.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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

daemon/spawn.c +8 -0
Index: 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)
maintainer
#7 lore raw
Quoted 42 lines · Matthias Koenig
Quoted 40 lines · Ian Kent
Quoted 39 lines · Jeff Moyer
Quoted 36 lines · Ian Kent
Quoted 25 lines · Matthias Koenig
Quoted 23 lines · Ian Kent
Quoted 21 lines · 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.

Quoted 8 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

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

maintainer
#8 lore raw
In reply to Matthias Koenig
Quoted 11 lines · 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

Quoted 5 lines

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

maintainer
#9 lore raw
In reply to Matthias Koenig
Quoted 14 lines · 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

Quoted 6 lines

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

#10 lore raw
Quoted 8 lines · Ian Kent
Quoted 7 lines · 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:

Quoted 7 lines
Quoted 7 lines

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.

Quoted 10 lines
Quoted 6 lines

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

Quoted 3 lines

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

maintainer
#11 lore raw
Quoted 42 lines · Matthias Koenig
Quoted 8 lines · Ian Kent
Quoted 7 lines · 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:

Quoted 7 lines
Quoted 7 lines

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.

Quoted 10 lines
Quoted 6 lines

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

Quoted 6 lines
Quoted 3 lines

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.

Quoted 29 lines

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

#12 lore raw
Quoted 8 lines · Ian Kent

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

maintainer
#13 lore raw
In reply to Matthias Koenig
Quoted 5 lines · Matthias Koenig

Ian Kent <[email protected]> writes:

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

Quoted 7 lines

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.

Quoted 13 lines

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.

Quoted 4 lines
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