Is it possible to find out what files and applications are being used on a nfs share from the server side?

We make files/applications available to our users from a (read-only) nfs share. It has not been cleaned in the last 10 years. Can I find out what our users are still using without monitoring them client side?

I've tried looking at access times, but they don't get updated on the server. I've tried looking at the locking daemon, but no files/directories seems to get locked. I guess because it's mounted read-only.

The server is mostly up to date, we update once or twice a year and unattended-upgrades is running for security updates. The data has been accumulating for 10 years.
Debian 9
Kernel 4.9.0-4-amd64
nfs-kernel-server 1:1.3.4-2.1

  • Since it's running for 10 years, the details of the server configuration might be important: what comes to mind are server kernel version and perhaps linux distribution. Feb 7, 2019 at 6:26

4 Answers 4


How about using Wireshark and capturing or filtering for NFS port?

You would be able to see the different actions and what is being requested.

  • I didn't think of that. I'll try it, thanks for the suggestion. Will post here if and how I succeed. Feb 7, 2019 at 10:25
  • Since I don't have a gui, I used tshark. With the following command I got to see which files were being accessed "tshark -Y "rpc.program == 100003 && nfs.main_opcode == 18" -o nfs.file_name_snooping:true -o nfs.file_full_name_snooping:true -T fields -e nfs.fhandle -e nfs.name", but it gave a segmentation fault very quickly. It also doesn't show the path yet, so I'll need to figure out how to get that. I also need to figure out how to NOT slow down the entire server while doing this. Feb 7, 2019 at 16:03
  • I think I would lean toward something like (not tested) tshark -V -d tcp.port==2049,rpc net -o 'nfs.file_name_snooping:TRUE' -o 'nfs.file_full_name_snooping:TRUE' -o 'nfs.default_fhandle_type:KNFSD_LE' -s 300 because of the tcp.port. Feb 8, 2019 at 16:58
  • tshark: -o flag "nfs.default_fhandle_type:KNFSD_LE" specifies unknown preference. The output I'm getting without that option is plentiful, but useless. Feb 12, 2019 at 10:15

You could use lsof -N <share> It will only show the files that are currently being used. But you could maybe script something over a course of a few days to build a list of documents. Just a thought

  • 1
    I've tried this, but it doesn't seem to work. As a user I opened a few files on the NFS share. I started a program from the share and opened another file in vi. Then as root on the server I do 'lsof -N <my share>' and I don't see the files my user account has opened. I only see the share is in use. Feb 7, 2019 at 11:30

I've only found two ways to do this. One is to use Systemtap on the server.

The other is to query every NFS client using lsof -N. You can get a list of clients by running showmount. If you have ssh keys set up, this script is a starting point. If you're looking for a specific volume/mount you can add in a pattern to grep for.

mkdir /var/tmp/output.$$
for ip in `showmount --no-headers` ; do
  ssh -n $ip /usr/sbin/lsof -N > /var/tmp/output.$$/$ip &
cat /var/tmp/output.$$/* | awk '{print $9,$10}' | sort -u
rm -rf /var/tmp/output.$$

In addition to using Wireshark (apt-get install tshark on a Debian system; then use something like tshark -f 'port 2049 && host' -i eth0 -w savefile -P -t ad and e.g. read it with Wireshark later ), one might want to apply bcc -- for example, use trace.py utility as follows:

# trace.py -n nfsd \
  'vfs_open(const struct path *pP, struct file * pF)  (pP->dentry) "%s (%d)", pP->dentry->d_name.name,pP->dentry->d_inode->i_ino'

PID     TID     COMM            FUNC             -
12333   12333   nfsd            vfs_open         testfile (1337)
12333   12333   nfsd            vfs_open         testdir (1336)

This was the result of a simple cd testdir; echo 'abc' >testfile on the client mounting the share .

d_name.name here would be of course the name of the file, and d_inode->i_ino would be its inode number. So, if the exported filesystem is known, a single file could be found by e.g. find $path -inum $inode.

( In the case if there are inner filesystems exported with nohide or crossmnt options under the same root, find may find more than one entry -- in which case the filename may help to identify the correct one. )

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.