If you’re running Audiobookshelf on a NAS and your library lives on a CIFS, SMB, sshfs, or NTFS mount, scans can take hours. Manual partial scans that should finish in seconds pin all your CPU cores and saturate 200-300 Mbps of network bandwidth while Plex finishes a comparable library in under a minute.

The debug log for your scan will be full of lines like this:

Library item "Author/Book Title" key "ino" changed from "827328" to "1121761"
Library item "Author/Book Title" key "mtime" changed from "1699894581000" to "1699894581578"
Library item "Author/Book Title" key "ctime" changed from "1699894581000" to "1699894581578"
Library item "Author/Book Title" key "birthtime" changed from "0" to "1699831480927"

Audiobookshelf uses the filesystem inode number to track library items across renames. Every scan, it compares the current inode (plus mtime, ctime, birthtime) against what it stored last time. If any of those changed, the item is treated as modified and ABS runs ffprobe on every audio file inside it to pick up new tags, codec, bitrate, and chapters. For a 2,000 book / 125,000 file library, that’s hours of CPU every single scan.

The problem is that a lot of network filesystems don’t produce stable inode values. CIFS without the serverino mount option generates inode numbers on the client side, so they change every time you remount. sshfs constructs them from file paths, and they can drift across versions or remounts. NTFS volumes mounted via ntfs-3g in Docker show similar behavior. The scanner ends up treating every item as new, every time.

The relevant check is in the server’s LibraryItemScanData.js. Inode, path, mtime, ctime, and birthtime are all part of the comparison. The maintainer confirmed that ABS relies on stable inodes to detect renames, so the fix has to happen on the filesystem side.

Step 1: confirm it’s the inode problem

Turn on debug logs in Settings > Logs, then run a partial scan. Open the scan log under metadata/logs/scans/ and search for key "ino" changed. If most of your library items have this line, you’ve found your culprit.

You can confirm directly with stat too. Open a shell inside your Audiobookshelf container and pick any book folder:

stat /audiobooks/Author\ Name/Book\ Title/

Note the Inode number. Restart the mount (or the container), then run the same stat again without touching any files. If the inode changed, you have transient inodes. That’s the root cause.

Fix 1: CIFS / SMB, add the serverino mount option

serverino tells the CIFS client to use inode numbers reported by the Samba server instead of making them up locally. This is the cleanest fix if the server supports it (modern Samba does by default).

If you mount the share from /etc/fstab, change your entry to include serverino and cache=strict:

//nas.local/audiobooks /mnt/audiobooks cifs credentials=/root/.smbcreds,serverino,cache=strict,uid=99,gid=100,iocharset=utf8 0 0

cache=strict also helps, because loose CIFS caching can cause timestamps to flap between scans. Unmount and remount to apply:

umount /mnt/audiobooks && mount /mnt/audiobooks

Then run stat before and after a container restart to confirm the inode is now stable.

On Unraid, the Unassigned Devices plugin doesn’t expose serverino in its UI. You can either mount the share manually in /boot/config/go with the full mount command above, or move your audiobooks to a local array share. More on that in Fix 4.

Fix 2: sshfs, switch to NFS

sshfs constructs inodes from file paths. They look persistent while the mount is live, but remounting can change them, and there’s no serverino equivalent. The user who opened the original issue noted the same behavior after switching from sshfs.

If you’re using sshfs because NFS seemed like too much work, it’s worth the switch. NFSv3 and v4 expose stable inode numbers from the remote server by default, and they perform better for large directory scans. Change your fstab entry from:

user@nas:/audiobooks /mnt/audiobooks fuse.sshfs defaults,_netdev 0 0

to:

nas.local:/export/audiobooks /mnt/audiobooks nfs defaults,_netdev 0 0

…and export the share properly from the NAS side. The NAS setup guide has a Synology / TrueNAS / Unraid layout that works well.

Fix 3: NTFS volumes in Docker

Several users reported the same long scans on NTFS volumes mounted into their Docker host. NTFS inodes via ntfs-3g aren’t guaranteed to survive remounts, especially if the Docker service restarts the bind mount.

If your library is on an NTFS drive because you share it with a Windows machine, you’re stuck between a few tradeoffs:

• Reformat to ext4 or XFS and share back to Windows via SMB from your NAS. Cleanest option.
• Run ABS natively on the Windows machine instead of in Docker, so you’re using the native NTFS driver directly.
• Avoid remounting between scans. This is a bandage, not a fix. Your inodes will still reset if Docker restarts the volume.

Fix 4: move the library to local storage

If none of the above works for your setup, moving the audiobook files to a local disk on the same machine as ABS is the sledgehammer fix. The original reporter confirmed their scans dropped dramatically after moving everything to local Unraid array storage. Response time for playback improved too.

On Unraid specifically, using an exclusive share pointed at the cache SSD works well. You get NVMe speeds for scans while still keeping the files accessible over SMB for uploads from other machines.

Check your free space first. A 1,000 book library is often 300-500 GB.

Do not disable “Audio file meta tags”

You’ll find advice on Reddit suggesting you turn off Audio file meta tags in the library scanner settings. This can make scans finish faster in some cases, but the maintainer clarified that ffprobe still runs regardless. ABS needs codec, bitrate, and chapter info from the probe even if you tell it to ignore tags. The apparent speedup is coincidence.

More importantly, disabling this option means ABS can’t use embedded tags to match your books to metadata providers. You’d trade scan speed for a less accurate library, and the scan isn’t actually faster for the reason you think.

Related: the inode problem also causes wrong metadata

The same transient inode behavior is responsible for a separate bug where newly added books inherit metadata from old ones. If you’re seeing that too, check the wrong metadata troubleshooting post. The root cause is shared, so a fix for one often fixes the other.

If you’re seeing long lags between adding a book on the server and it appearing in SoundLeaf, the scan is the first place to look. Slow scans don’t break the app directly, but new books won’t show up until the scan finishes, library searches can hit stale data mid-scan, and cover art requests get slow while the server is pinning CPU.

Affected versions

Users first flagged this on v2.7.0 in early 2024, and it’s still present in the current v2.33.x line. Multiple contributors including martinjgrunwald noticed the behavior started with 2.7 specifically, which lines up with the scanner rewrite around that version. The scanner still reads ino as part of keysToCompare in server/scanner/LibraryItemScanData.js, so the server-side behavior is unchanged.

The issue is backlogged upstream pending more reports from users who genuinely can’t get stable inodes from their filesystem. If that’s you, drop a note on the GitHub issue with your setup. More data points make a code-side fix more likely.