Comment 23 for bug 683938

So there is this freakish part of this bug which I had not considered before. Looking at the autofs4 code in the kernel, and the code in the automounter, there is no difference at all between the case where the directory doesn't exist on the server or the case where the mount security options are wrong, but only the latter produces the bug.

(Check the automount code. In spawn.c we find that spawn_mount is what calls the mount program, via do_spawn, and the return value is just the exit status of the program, which all ends up in the same packet sent to the kernel saying just that it failed, and the ioctl in the kernel turns that into ENOENT and the resulting paths are thus identical.)

Back in the day, mount.nfs always contacted the server itself to get a file handle for the root, and so errors like this were reflected really without entering the kernel at all. But that is not so. If you look at mount.nfs (from the nfs-utils source package), you find that mount.c does not behave the old way anymore. If the kernel version is > 2.6.22, then we get a new interface. Instead of using the nfsmount function, which did the old thing, we get the nfsmount_string function, which ends up passing everything to mount.

That means that the initial handshake with the server, which used to be in user space in the mount program, has (since 2.6.22) been moved into the kernel. I suspect the problem can be found there. Note that this is consistent with this bug appearing in lucid, but not existing in dapper, where we used a 2.6.18 kernel.