When you’re troubleshooting NFS issues, sometimes you have to collect a packet capture to see what’s going on. But the issue is, packet captures don’t really tell you the file or folder names. I like to use Wireshark for Mac and Windows, and regular old tcpdump for Linux. For ONTAP, you can run packet captures using this KB (requires NetApp login):
By default, Wireshark shows NFS packets like this ACCESS call. We see a FH, which is in hex, and then we see another filehandle that’s even more unreadable. We’ll occasionally see file names in the trace (like copy-file below), but if we need to find out why an ACCESS call fails, we’ll have difficulty:
Luckily, Wireshark has some built-in stuff to crack open those NFS file handles in ONTAP.
Also, check out this new blog:
Changing Wireshark Settings
First, we’d want to set the NFS preferences. That’s done via Edit -> Preferences and then by clicking on “Protocols” in the left hand menu and selecting NFS:
Here, you’ll see some options that you can read more about by mousing over them:
I just select them all.
When we go to the packet we want to analyze, we can right click and select “Decode As…”:
This brings up the “Decode As” window. Here, we have “NFS File Handle Types” pre-populated. Double-click (none) under “Current” and you get a drop down menu. You’ll get some options for NFS, including…. ONTAP! In this case, since I’m using clustered ONTAP, I select ontap_gx_v3. (GX is what clustered ONTAP was before clustered ONTAP was clustered ONTAP):
If you click “OK” it will apply to the current session only. If you click “Save” it will keep those preferences every time.
Now, when the ACCESS packet is displayed, I get WAY more information about the file in question and they’re translated to decimal values.
Those still don’t mean a lot to us, but I’ll get to that.
Mapping file handle values to files in ONTAP
Now, we can use the ONTAP CLI and the packet capture to discern exactly what file has that ACCESS call.
Every volume in ONTAP has a unique identifier called a “Master Set ID” (or MSID). You can see the volume’s MSID with the following diag priv command:
cluster::*> vol show -vserver DEMO -volume vol2 -fields msid vserver volume msid ------- ------- ----------- DEMO vol2 2163230318
If you know the volume name you’re troubleshooting, then that makes life easier – just use find in the packet details.
If you don’t, the MSID can be found in a packet trace in the ACCESS reply as the “fsid”:
You can then find the volume name and exported path with the MSID in the ONTAP CLI with:
cluster::*> set diag; vol show -vserver DEMO -msid 2163230318 -fields volume,junction-path vserver volume junction-path ------- ------- ----------- DEMO vol2 /vol2
File and directory handles are constructed using that MSID, which is why each volume is considered a distinct filesystem. But we don’t care about that, because Wireshark figures all that out for us and we can use the ONTAP CLI to figure it out as well.
The pertinent information in the trace as it maps to the files and folders are:
- Spin file id = inode number in ONTAP
- Spin file unique id = file generation number
- File id = inode number as seen by the NFS client
If you know the volume and file or folder’s name, you can easily find the inode number in ONTAP with this command:
cluster::*> set advanced; showfh -vserver DEMO /vol/vol2/folder Vserver Path ---------------------- --------------------------- DEMO /vol/vol2/folder
flags snapid fileid generation fsid msid dsid ------- ------ --------- ---------- ---------- ------------ ------------ 0x8000 0 0x658e 0x227ed312 - - 0x1639
In the above, the values are in hex, but we can translate with a hex converter, like this one:
So, for the values we got:
- file ID (inode) 0x658e = 25998
- generation ID 0x227ed312 = 578736914
In the trace, that matches up:
Finding file names and paths by inode number
But what happens if you don’t know the file name and just have the information from the trace?
One way is to use the nodeshell level command “inodepath.”
::*> node run -node node1 inodepath -v files 15447 Inode 15447 in volume files (fsid 0x142a) has 1 name. Volume UUID is: 76a69b93-cc2f-11ea-b16f-00a098696eda [ 1] Primary pathname = /vol/files/newapps/user1-file-smb
This will work with a FlexGroup volume as well, provided you know the node and the member volume where the file lives (see “How to Map File and Folder Locations to NetApp ONTAP FlexGroup Member Volumes with XCP” for a way to figure that info out).
::*> node run -node node2 inodepath -v FG2__0007 5292
Inode 5292 in volume FG2__0007 (fsid 0x1639) has 1 name.
Volume UUID is: 87b14652-9685-11eb-81bf-00a0986b1223
[ 1] Primary pathname = /vol/FG2/copy-file-finder
There’s also a diag privilege command in ONTAP for that. The caveat is it can be dangerous to run, especially if you make a mistake in running it. (And when I say dangerous, I mean best case, it hangs your CLI session for a while; worst case, it panics the node.) If possible, use inodepath instead.
Here’s how we could use the volume name and inode number to find the file name. For a FlexVol volume, it’s simple:
cluster::*> vol explore -format inode -scope volname.inode -dump name
cluster::*> volume explore -format inode -scope files.15447 -dump name name=/newapps/user1-file-smb
With a FlexGroup volume, however, it’s a little more complicated, as there are member volumes to take into account and there’s no easy way for ONTAP to discern which FlexGroup member volume has the file, since ONTAP inode numbers can be reused in different member volumes. This is because the file IDs presented to NFS clients are created using the inode numbers and things like the member volume’s MSID (which is different than the FlexGroup’s MSID).
To make this happen with volume explore, we’d be working in reverse – listing the contents of the volume’s files/folders, then using the inode number of the parent folder, listing those, etc. With high file count environments, this is basically an impossibility.
In that case, we’d need to use an NFS client to discover the file name associated with the inode number in question.
From the client, we have two commands to find an inode number for a file. In this case we know the file’s location and name:
# ls -i /mnt/client1/copy-file-finder 4133624749 /mnt/client1/copy-file-finder
#stat copy-file-finder File: ‘copy-file-finder’ Size: 12 Blocks: 0 IO Block: 1048576 regular file Device: 2eh/46d Inode: 4133624749 Links: 1 Access: (0555/-r-xr-xr-x) Uid: ( 1102/ prof1) Gid: (10002/ProfGroup) Access: 2021-04-14 11:47:45.579879000 -0400 Modify: 2021-04-14 11:47:45.588875000 -0400 Change: 2021-04-14 17:34:07.364283000 -0400 Birth: -
In a packet trace, that inode number is “fileid” and found in REPLY calls, such as GETATTR:
If we only know the inode number (as if we got it from a packet trace), we can use the number on the client to find the file name. One way is with “find”:
# find /path/to/mountpoint -inum <inodenumber>
# find /mnt/client1 -inum 4133624749
“find” can take a while – especially in a high file count environment, so we could also use XCP.
# xcp -l -match 'fileid== <inodenumber>' server1:/export
In this case:
# xcp -l -match 'fileid== 4133624749' DEMO:/FG2 XCP 1.6.1; (c) 2021 NetApp, Inc.; Licensed to Justin Parisi [NetApp Inc] until Tue Jun 22 12:34:48 2021 r-xr-xr-x --- 1102 10002 12 0 12d23h FG2/copy-file-finder Filtered: 8173 did not match Xcp command : xcp -l -match fileid== 4133624749 DEMO:/FG2 Stats : 8,174 scanned, 1 matched Speed : 1.47 MiB in (2.10 MiB/s), 8.61 KiB out (12.3 KiB/s) Total Time : 0s. STATUS : PASSED
Hope this helps you find files in your NFS filesystem! If you have questions or comments, leave them below.