Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

In an environment with automounted home directories, such that the same filesystem exported by a fileserver may be mounted multiple times on the client, I would like to authoritatively be able to identify whether two mountpoints are in fact the same filesystem. That is, if the remote server exports:


And the local client has:

# mount
fileserver:/home/l/lars on /home/lars type nfs (rw...)
fileserver:/home/b/bob on /home/bob type nfs (rw...)

I am looking for a way to identify that both /home/lars and /home/bob are in fact the same filesystem. In theory this is what the fsid result of the statvfs structure is for, but in all cases, for both local and remote filesystems, I am finding that the value of this structure member is 0.

Is this some sort of client-side issue? Or do most modern NFS servers simply decline to provide a useful fsid?

The end goal of all of this is to robustly interpret the output from the quota command for NFS filesystems. For example, given the example above, running quota as myself may return something like:

Disk quotas for user lars (uid 6580): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
                     12  52428800 52428800               4  4294967295 4294967295        
                9353032  9728000 10240000          124018       0       0        

...the problem here being that there exists a quota for me on otherserver which is visible in the results of the quota command, even though my home directory is actually on a different device. My plan was to look up the fsid for each mountpoint listed in the quota output and check to see if it matched the fsid associated with my home directory.

It looks like this won't work, so...any suggestions?

share|improve this question

1 Answer 1

up vote 3 down vote accepted

You can use the mountpoint command. The -d switch prints the major/minor device number of the mount point to stdout.

In your case, compare the output of mountpoint -d /home/lars to mountpoint -d /home/bob.

[root@Fruity ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             9.9G  2.5G  7.0G  26% /
/dev/sda1              97M   43M   50M  47% /boot
/dev/sda7             2.0G   68M  1.9G   4% /tmp
/dev/sda3             9.9G  2.8G  6.6G  30% /usr
/dev/sda6             6.0G  1.1G  4.6G  19% /var
/dev/sdb1             400G  263G  138G  66% /data
/dev/sdc1             150G  122G   29G  82% /images
nfs001:/data/chain    36G  1.2G   35G   4% /data/chain
nfs001:/data/src      36G  1.2G   35G   4% /data/src

[root@Fruity ~]# mountpoint -d /data/chain/

[root@Fruity ~]# mountpoint -d /data/src/

[root@Fruity ~]# mountpoint -d /data/
share|improve this answer
That's exactly what I'm looking for. More importantly, looking at the strace output for mountpoint, it reminds me that I can just call stat() on a filesystem and get use the st_dev member, which is exactly what mountpoint is doing. Thanks! –  larsks Mar 20 '12 at 3:14
Excellent. Good to know that works. –  ewwhite Mar 20 '12 at 17:22
st_dev customarily uniquely identifies a device but is not required to do so. For example some POSIX-like implementations set st_dev=-1 for all NFS filesystems. To be certain you need to use the combination of st_dev and the st_ino value of the top directory in the filesystem. And that is just what mountpoint is doing. Also bear in mind that these techniques do not work for AFS. –  James Youngman Mar 22 '12 at 0:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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