15

My error is:

mount.nfs4: access denied by server while mounting fileserver:/export/path/one

My question is:

where would the detailed log information be on the server (under systemd)?

More information:

I asked a similar question from the Ubuntu client perspective on AskUbuntu. My focus in this question is on the Arch Linux server. In particular, I am looking for logs on the server that will help me understand the problem.

Here's the background:

Our small LAN is running an Arch Linux NFS v4 file server. We have several clients running Ubuntu 15.10 and 16.04. We have one client running Ubuntu 14.04. The 14.04 client will not connect to the file server. The others all connect fine. The settings are the same on all clients. And all clients are listed in /etc/exports on the server.

I need to find more detailed error information on the Arch linux server. However, journalctl does not show anything related to nfs and it does not contain any entries that are related to the nfs access denied errors.

The 14.04 client can ping the fileserver as well as log in via SSH. The user name / ID as well as group match. (I'm using the same user account / uid on both client and server. It is uid 1000.)

Even more info:

$ sudo mount -a (on client) mount.nfs4: access denied by server while mounting fileserver:/export/path/one mount.nfs4: access denied by server while mounting fileserver:/export/path/two

The client can ping the fileserver (and vice versa):

$ ping fileserver PING fileserver (192.168.1.1) 56(84) bytes of data. 64 bytes from fileserver (192.168.1.1): icmp_seq=1 ttl=64 time=0.310 ms

The client successfully logs into the LAN-based fileserver:

$ ssh fileserver Last login: Tue Aug 16 14:38:26 2016 from 192.168.1.2 [me@fileserver ~]$

The fileserver's mount export and rpcinfo are exposed to the client:

$ showmount -e fileserver # on client Export list for fileserver: /export/path/one/ 192.168.1.2 /export/path/two/ 192.168.1.2,192.168.1.3 $ rpcinfo -p fileserver (on client) program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 58344 status 100024 1 tcp 58561 status 100005 1 udp 20048 mountd 100005 1 tcp 20048 mountd 100005 2 udp 20048 mountd 100005 2 tcp 20048 mountd 100005 3 udp 20048 mountd 100005 3 tcp 20048 mountd 100003 4 tcp 2049 nfs 100003 4 udp 2049 nfs

This is the error when mounting the export directly:

$ sudo mount -vvv -t nfs4 fileserver:/export/path/one /path/one/ mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "fileserver:/export/path/one" mount: node: "/path/one/" mount: types: "nfs4" mount: opts: "(null)" mount: external mount: argv[0] = "/sbin/mount.nfs4" mount: external mount: argv[1] = "fileserver:/export/path/one" mount: external mount: argv[2] = "/path/one/" mount: external mount: argv[3] = "-v" mount: external mount: argv[4] = "-o" mount: external mount: argv[5] = "rw" mount.nfs4: timeout set for Tue Aug 16 16:10:43 2016 mount.nfs4: trying text-based options 'addr=192.168.1.1,clientaddr=192.168.1.2' mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting fileserver:/export/path/one
Improve this question
9
  • Your showmount -e is showing a / character at the end of each directory. That might be confusing things. On fileserver ensure your exports says /export/path/one and not /export/path/one/ Commented Aug 17, 2016 at 0:02
  • I made the change to remove trailing slash from /etc/exports. I ran exportfs -ra and systemctl restart nfs-server.service. I still get the same error on the client. Commented Aug 17, 2016 at 0:07
  • If you try to mount fileserver:/path/one , does that work? Commented Aug 17, 2016 at 11:01
  • @MarkPlotnick - no, mount fileserver:/path/one does not work. Trying different permutations of the trailing slash doesn't seem to have any effect. Commented Aug 19, 2016 at 5:27
  • OK. With NFSv4, it's customary to omit the /exports portion of the path when asking to mount the filesystem. Commented Aug 19, 2016 at 13:36

3 Answers 3

Reset to default
23

It looks like the underlying problem was solved by @pgoetz, but for posterity I'll address the original question about how capture NFS logs (I had similar issues but couldn't find an answer about logging either!).

Detailed logging for both the NFS server and its clients can be obtained using rpcdebug, which will generate kernel logs (so they'll show up in, e.g. /var/log/messages, /var/log/syslog, etc. depending on your distro).

The general form is rpcdebug -m [module] -s [flags]:

  • -m [module]: this specifies the module to log. This can be nfs, nfsd, rpc, or nlm -- for general NFS logs on the server, use nfsd; for general NFS logs on the client, use nfs
  • -s [flags]: this sets the debugging flag(s) that you want the kernel to log. The flags available depend on the module

(see man rpcdebug for more information)

So, example commands to start logging all flags can be:

  • NFS server: rpcdebug -m nfsd -s all
  • NFS clients: rpcdebug -m nfs -s all

Note: this will be very verbose. The flags can be tweaked to get the right logging level, but starting with all flags can help narrow down the issue.

For fewer log entries, clear the all flag and then set specific flags to track, e.g.:

$ rpcdebug -m nfsd -c all # clear all flags to stop logging them $ rpcdebug -m nfsd -s auth proc # set the auth and proc flags instead of logging all flags
Improve this answer
2
  • Thanks for this, however, I'm NOT getting anything even after setting BOTH server and client, "rpcdebug -m nfsd -s all" (one of them wouldn't take all so I specified them all, and that was taken). Still no data in EITHER log, though the server ticks over a lot of stuff from other clients. ... Any ideas? Commented Oct 5, 2022 at 0:07
  • For beginners, if it's not clear, after running the rpcdebug commands, then check the log files, e.g. sudo tail -f /var/log/syslog is where I had rpc.mountd logs come up in on Debian. (in my case, on the server end, the issue was "unmatched host". Commented Oct 21, 2023 at 22:45
4

rpc.mountd is the component responsible for responding to mount requests coming from the kernel (NFSv4) or from clients (NFSv3). It doesn't log anything by default.

  • Edit /etc/nfs.conf → [mountd] and set debug="auth"
  • Restart nfs-mountd.service
  • Watch the logs with journalctl -u nfs-mountd

A successful mount operation will log:

Jul 26 18:59:41 rpc.mountd[44663]: successful authentication for IP 192.0.2.4 as * Jul 26 18:59:41 rpc.mountd[44663]: v4.2 client attached: 0xfd56f6df66a3f20b from "192.0.2.4:919" Jul 26 18:59:41 rpc.mountd[44663]: granted access to / for * Jul 26 18:59:41 rpc.mountd[44663]: granted access to /srv for * Jul 26 18:59:41 rpc.mountd[44663]: granted access to /srv/data for *

If rpc.mountd rejects a mount request then you should see the reason logged here.

If you want IP addresses to be logged instead of the client name (* in my example above) then set cache-use-ipaddr=y. In this case it's a good idea to also set ttl=3600, so that a client that continues to access a filesystem doesn't cause too much log file spam. In this case, mount operations will mount:

Dec 10 15:11:41 rpc.mountd[1410]: successful authentication for IP 192.0.2.4 Dec 10 15:11:41 rpc.mountd[1410]: v4.2 client attached: 0xa9f64fd5675739d6 from "192.0.2.4:717" Dec 10 15:11:41 rpc.mountd[1410]: granted access to / for 192.0.2.4 Dec 10 15:11:41 rpc.mountd[1410]: granted access to /srv for 192.0.2.4 Dec 10 15:11:41 rpc.mountd[1410]: granted access to /srv/data for 192.0.2.4

For more details about these changes, see SUSE's Improved NFS v4 Server logging of client access article.

Improve this answer
3

I was having exactly the same problem, with both client and server Arch linux. The solution was to use the hostname in /etc/exports instead of the IP address. I changed this:

/srv/nfs 192.168.10(rw,fsid=root,no_subtree_check) /srv/nfs/media 192.168.10(rw,no_subtree_check) /srv/nfs/share 192.168.10(rw,no_subtree_check)

To this:

/srv/nfs iguana(rw,fsid=root,no_subtree_check) /srv/nfs/media iguana(rw,no_subtree_check) /srv/nfs/share iguana(rw,no_subtree_check)

This resulted in a slightly different problem:

[root@iguana data]# mount -t nfs4 frog:/srv/nfs/media /data/media mount.nfs4: Protocol not supported

I don't have a lot of experience with NFS4; apparently you are not supposed to include the NFS root path in the mount command. This finally worked and mounted the volume:

[root@iguana data]# mount -t nfs4 frog:/media /data/media
Improve this answer
2
  • 11
    Just a point of order: this shouldn't be accepted as an answer to the question "Where are NFS v4 logs under systemd?" which is the title of this question as I write this comment. Commented May 17, 2022 at 13:54
  • I dont understand how changing the fstab will get the nfs daemon to log, nor does this state where. Commented May 9 at 2:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.