Bug 208071

Summary:	AutoFS seems to disturb NFS server
Product:	Base System	Reporter:	dlt_cjo
Component:	kern	Assignee:	Edward Tomasz Napierala <trasz>
Status:	Closed Not A Bug
Severity:	Affects Some People	CC:	amd64, rmacklem, trasz
Priority:	---
Version:	10.2-RELEASE
Hardware:	amd64
OS:	Any

Description dlt_cjo 2016-03-16 19:42:04 UTC

I'm currently working to move my organization from am-utils to autofs and have run into a snag.  I've got three non-prod FreeBSD 10.2-RELEASE-p13 (as reported by freebsd-version) machines that export NFS.  If I'm transferring data from a client and attempt an autofs mount elsewhere on the server, the mount between the client and server seems to be disturbed in a way that I haven't been able to define, as there's no in-your-face error.

To recreate:

* Export a file system on the NFS server(nfs3).
* NFS mount the server from a client(nfs3).
* Run an automatic iozone benchmark from the client on the NFS mount. (iozone -a)
* ssh into the server, change directory into an autofs namespace, then do a directory listing to cajole it into mounting a file system on yet another NFS machine(nfs3).
* The NFS client running the iozone should now error out with a "Can not open temporary file iozone.tmp for read, open: Permission denied" or "fsync: Input/output error"

I can't quite place my finger on it.  It seems as if the act of mounting another filesystem with AutoFS is disturbing the NFS server in some way.  

This doesn't happen when using a similarly configured am-utils as the automounter & I'm able to duplicate on all three FreeBSD machines.  Running automountd in debug mode doesn't seem to report any errors that would lead me to believe it's a configuration issue. (Though I'm certainly open to that being a problem!)

Comment 1 Edward Tomasz Napierala freebsd_committer

2016-03-17 11:00:29 UTC

To clarify: the problem occurs when trying to automount an NFS share on the NFS server itself, right?  Does it also occur if you try to mount the share by hand (mount -t nfs)?

Comment 2 dlt_cjo 2016-03-17 12:21:16 UTC

(In reply to Edward Tomasz Napierala from comment #1)

Yes - this happens when automounting from the server.

It does in fact, do that when I mount by hand on the server on the server as well..Something I didn't test.

I was also able to duplicate on 9.3-RELEASE-p21 machine that does not use AutoFS by mounting another export by hand. 

I was unable to duplicate on NFS servers running Linux kernel 3.16.0 and 2.6.32 with the same nfs client machine running iozone for reference.

This is what the NFS related things look like in my rc.conf: (Maybe I'm doing something that is incorrect)
mountd_enable="YES"
rpcbind_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
nfs_client_enable="YES"
nfs_server_enable="YES"

Apologies for thinking this was an AutoFS problem - It's now clear to me that it's not!

Do you have any thoughts on where the problem could be?

Comment 3 Edward Tomasz Napierala freebsd_committer

2016-03-18 12:54:25 UTC

Sorry, no idea.  I've asked Rick Macklem, the NFS author and maintainer, to take a look.

Comment 4 dlt_cjo 2016-03-18 18:45:08 UTC

(In reply to Edward Tomasz Napierala from comment #3)

Thank you, I appreciate it!

Comment 5 Rick Macklem freebsd_committer

2016-03-19 02:06:40 UTC

Every time you mount(8) any file system on the NFS server, mountd reloads
the /etc/exports. This has two effects:
1 - Unless you are running mountd with the "-S" option, the file systems
    will become unexported for a short period of time during the reload.
2 - If the new file system is mounted on top of the exported file system,
    mountd will try to export that new file system.
    --> NFS mounts can never be exported, so if the new file system is
        an NFS client mount, the export will no longer work. (This has
        been the case since 1985 and is in part the case because you
        can't safely put a file handle inside a file handle.)

To fix #1, add "-S" to mountd_flags.
#2 just won't work and needs to be avoided. You can look at
/var/log/messages for entries related to export problems generated
by mountd.

I don't know amd-utils or autofs, but it may be that one of them uses
mount(8) and the other does not. FreeBSD's mount(8) always sends a
SIGHUP to mountd, which makes it reload /etc/exports.

Basically #1 and #2 only occurs because mountd reloads /etc/exports
and that happens when mountd receives a SIGHUP. It may be that amd-utils
doesn't send a SIGHUP to mountd?)

rick

Comment 6 dlt_cjo 2016-03-19 13:18:03 UTC

(In reply to Rick Macklem from comment #5)

Rick-

You have solved my mystery.  Giving mountd the -S argument worked!

Thank you, it's certainly appreciated.