Trace XFS Inodes Back to Paths with xfs_ncheck

A log message, crash dump or recovery tool has given you an inode number and nothing else, and xfs_ncheck is how you turn that back into a filename. It reads the filesystem metadata and prints inode numbers with the paths it can resolve. The command is for XFS only, and it does not repair a filesystem or change files.

Allow about ten minutes. You need the xfsprogs package and read access to the XFS device. These examples use xfs_ncheck 6.6.0 from xfsprogs 6.6.0-1ubuntu2.1.

1. Confirm the installed command

Check which binary will run and record its version:

$ command -v xfs_ncheck
/usr/sbin/xfs_ncheck
$ xfs_ncheck -V
xfs_ncheck version 6.6.0

The exact version will differ on another system. If the command is missing, install xfsprogs through your normal package-management process. Do not copy an inode-reporting command from another filesystem type and assume it understands XFS metadata.

2. Choose the correct device

The final argument is the disk or volume device containing the XFS filesystem. It is not the directory where that filesystem happens to be mounted. For a logical volume, the value may look like /dev/mapper/vg_data-lv_archive. For a partition, it may be /dev/nvme0n1p3.

Before opening a real device, identify it without changing anything:

$ findmnt -t xfs
TARGET  SOURCE                         FSTYPE OPTIONS
/srv    /dev/mapper/vg_data-lv_archive xfs    rw,relatime
$ lsblk -f /dev/mapper/vg_data-lv_archive
NAME                      FSTYPE LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
vg_data-lv_archive        xfs          01234567-89ab-cdef-0123-456789abcdef    42G    31% /srv

3. Generate the complete inode and pathname report

Pass the XFS device with no -i option:

$ sudo xfs_ncheck /dev/mapper/vg_data-lv_archive
128 /srv
256 /srv/reports
257 /srv/reports/quarterly.csv

The output is an inode number followed by a pathname. Directory entries are marked with a trailing slash by the command. The report is not sorted in a promised order, so do not compare two runs line by line or treat the first result as the oldest or newest file.

On a large filesystem, this can produce a lot of output. Save it to a new file if you need to search it, and check the command status immediately:

$ sudo xfs_ncheck /dev/mapper/vg_data-lv_archive > xfs-ncheck.txt
$ status=$?
$ printf 'xfs_ncheck exit status: %s\n' "$status"
xfs_ncheck exit status: 0
$ rg 'quarterly\.csv| 128 ' xfs-ncheck.txt

Redirection creates or truncates xfs-ncheck.txt. Use a new destination or make a backup first if that name already contains a report you need. The command itself does not write to the filesystem being examined.

4. Look up selected inode numbers

Use -i when you already have an inode number. Repeat the option for multiple numbers:

$ sudo xfs_ncheck -i 256 -i 257 /dev/mapper/vg_data-lv_archive
256 /srv/reports
257 /srv/reports/quarterly.csv

This is a filter, not a request to generate new inode numbers. An inode that has been deleted, belongs to another filesystem, or was copied incorrectly may produce no matching line. Check the device and the number before treating an empty result as proof that a file never existed.

Keep the option and its value together. For scripts, quote a value supplied by a user only after validating that it is an expected numeric inode identifier. Do not turn untrusted text into a shell command.

5. Narrow the report to security-sensitive entries

The -s option limits output to special files and files with set-user-ID mode, which the manual notes can help detect violations of security policy:

$ sudo xfs_ncheck -s /dev/mapper/vg_data-lv_archive
412 /srv/tools/helper

This is a report filter, not a security fix. It does not remove set-user-ID bits, change ownership, or prove that a file is safe. Preserve the device state while you investigate the results. Any later permission change is a separate, potentially security-sensitive operation that needs its own review and rollback plan.

6. Inspect an XFS image file

If the filesystem is stored in an ordinary file, add -f. This is common for an image copy made from an XFS filesystem:

$ xfs_ncheck -f /path/to/xfs-image.raw
128 /
256 /lost+found/

The -f option changes how device is opened. It does not convert a non-XFS file into XFS and it does not repair an image. Keep the original image unchanged and work from a verified copy when investigating evidence.

An external XFS log needs its own device with -l:

$ sudo xfs_ncheck -l /dev/mapper/vg_data-lv_log /dev/mapper/vg_data-lv_archive

Use -l only when the filesystem was created with an external log. Supplying an unrelated device can make the inspection fail or describe the wrong metadata layout. If you do not know the filesystem layout, stop and confirm it with the storage or backup documentation before guessing.

7. Handle failures without guessing

A missing device is a path problem, not evidence of an empty filesystem:

$ xfs_ncheck -f /path/to/missing-image
xfs_ncheck: cannot open /path/to/missing-image: No such file or directory

Check the path, permissions and filesystem type before retrying. If the tool reports corruption, or says the filesystem is very busy and looks corrupt, stop repeated scans and involve the person responsible for storage recovery. The manual notes that messages similar to an xfs_db check may appear in that situation.

Do not assume a mounted filesystem is safe to scan merely because the command opens it. A busy filesystem can change while you are reading it. Prefer an unmounted copy, snapshot or image for forensic work. If you must inspect a live volume, record that limitation in the report and avoid treating the output as a stable point-in-time inventory.