Bug 243551
| Summary: | Cannot checkout src tree in automounted $HOME | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Joerg Wunsch <joerg> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | New --- | ||
| Severity: | Affects Only Me | CC: | danielsh, emaste, rew, trasz |
| Priority: | --- | ||
| Version: | 12.1-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Joerg Wunsch
2020-01-23 20:47:38 UTC
^Triage: to submitter: is this still relevant in the post-SVN world? (In reply to Mark Linimon from comment #1) IMHO, SVN just uncovered a bug that is actually somewhere deeper in the system. So, in terms of SVN, this could probably be closed, but the bug would remain. ^Triage: incorporate feedback. I was only doing PR triage, so I won't be able to tackle this one myself, sorry. Edward any suggestions on next steps for obtaining diagnostic information? For a simple test, use something like this:
#include <sys/stat.h>
#include <stdio.h>
int
main(void)
{
struct stat sb;
int rv = stat("/home/foobar", &sb);
printf("stat() got %d\n", rv);
return 0;
}
/home/foobar is supposed to be a directory that would never exist since there is no such user "foobar". After running the above on an automounted /home, /home/foobar has been created. Trying to access anything there yields
Jun 23 21:03:51 daemon automountd[33777]: "mount -t nfs -o nfsv4,automounted,retrycnt=1 alfred.sax.de:/home/foobar /home/foobar/", pid 33833, terminated with exit status 1
Jun 23 21:03:51 daemon kernel: WARNING: autofs_trigger_one: request for /home/foobar/ completed with error 5
Jun 23 21:03:51 daemon automountd[33777]: mount failed
Jun 23 21:03:53 daemon automountd[34841]: "mount -t nfs -o nfsv4,automounted,retrycnt=1 alfred.sax.de:/home/foobar /home/foobar/", pid 35155, terminated with exit status 1
Jun 23 21:03:53 daemon kernel: WARNING: autofs_trigger_one: request for /home/foobar/ completed with error 5
Jun 23 21:03:53 daemon automountd[34841]: mount failed
Jun 23 21:03:54 daemon automountd[35511]: "mount -t nfs -o nfsv4,automounted,retrycnt=1 alfred.sax.de:/home/foobar /home/foobar/", pid 35610, terminated with exit status 1
Jun 23 21:03:54 daemon kernel: WARNING: autofs_trigger_one: request for /home/foobar/ completed with error 5
Jun 23 21:03:54 daemon automountd[35511]: mount failed
I agree with Joerg's diagnosis: it appears automountd(8) creates the mountpoint even though it shouldn't, and then (correctly) fails to mount it. I'm not sure why it's doing that, though. (In reply to Edward Tomasz Napierala from comment #6) Sure would be nice to have the errno from the failing mount program as it exited. I *think* this is what's happening: 1. automountd creates /home/foobar because it needs somewhere to mount the NFS filesystem. 2. automountd attempts to mount_nfs /home/foobar from the nfs server. 3. The nfs server replies with ENOENT (because /home/foobar doesn't exist on server). 4. the mount program fails and exits with status code 1. 5. automountd doesn't remove /home/foobar after the failed mount. One thought is; make a special case for NFS that checks if the target directory is exported from the NFS server before attempting to mount it. Not sure how feasible this idea is, I'd have to look into it..or maybe one of you know off the top of your head? I imagine an issue with doing a special case for NFS is that other automounted filesystems may have similar problems as well (but in a different way). Still, given that NFS seems to be the largest use-case for automount, it may be worth making a special case for NFS, even if the problem remains for other automounted filesystems. This is why I mentioned it would be nice to have the errno from the failing mount program as it *might* work as general solution for other automounted filesystems. We already have a mechanism for this kind of check: special maps. Kind of how special_hosts works, but looking up usernames instead of hosts. I've done a quick test, and it appears that "cd /net/nonexistent" does not result in that directory being created. So, special case could consist of a new map, say, special_users, which would first verify the username using getent(1). Another thing we could do is to remove the (newly created) mountpoint if mount fails, before releasing the process which triggered the mount. (In reply to Edward Tomasz Napierala from comment #8) To me, the latter (remove the temporary mountpoint before proceeding) sounds like the right way to go. When using a direct map with a wildcard entry and doing "cd /net/nonexistent", a new directory will be created. W.R.T. a special_users map, just because the user exists on the system doesn't necessarily mean that the users home directory is being exported via NFS, no? The temporary mountpoint should definitely be cleaned up on failure. I suppose this cleanup should happen after autofs has exhausted its retry attempts? Do you think autofs or automountd (via request from autofs) should do the clean up? Quick glance through the code; looks like it would be a bit of work to make the mount_nfs bits public that would allow automountd to retrieve the error code that was returned from the NFS server.. There's not a reliable way to discover exported directories for NFSv3/NFSv4? I think in a perfect world, the program flow would be: 1. request to automountd to mount from a NFS server 2. automountd checks if that directory is exported from the NFS server 3. if yes, create the temporary mountpoint 4. attempt the mount 5. if error, remove temporary mountpoint and return the error code to autofs 6. let autofs, based on the error code, decide if it wants to retry to mount. But, it's not a perfect world, is it? |