If you delete a book from disk, Audiobookshelf does not drop it from the library. The item gets flagged as “missing” and keeps showing up on the home screen and in lists, including in clients like the web reader and SoundLeaf. There is no “rescan and clean up” toggle in the settings, and a normal user account does not get a delete button on the item, so it looks like the entry is stuck. It isn’t stuck. You need to use the Issues filter on the web client, as an admin or root user.

Why ABS holds onto deleted files

The server tracks every library item by path and inode, and a missing path is treated as a possibly-temporary condition rather than a delete signal. When a scan can’t find an item’s files, the scanner sets isMissing = true on the row instead of removing it. You can see it in server/scanner/LibraryScanner.js:

libraryScan.addLog(LogLevel.WARN, `Library Item "${existingLibraryItem.path}" (inode: ${existingLibraryItem.ino}) is missing`)
libraryScan.resultsMissing++
if (!existingLibraryItem.isMissing) {
  libraryItemIdsMissing.push(existingLibraryItem.id)
  // ...
  libraryItem.isMissing = true
  await libraryItem.save()
}

advplyr (the project owner) explained the reasoning on the tracking issue #3765: the goal is to avoid throwing away progress, manual matches, and edited metadata when something looks gone for the wrong reason. Two common cases trip a false “missing” flag:

• A filesystem that doesn’t expose stable inode values (some CIFS and SMB mounts). A folder rename can look identical to a delete plus a fresh create. If ABS auto-deleted on missing, the rename would wipe the metadata. Related: the CIFS inode churn problem.
• A Docker volume path that got changed by accident. The whole library appears missing until the path is fixed; auto-delete would have nuked every row before the user could revert.

Clear missing items from the Issues filter

The library page has an Issues filter that narrows the view to items in trouble (missing files, missing parts, invalid metadata). When that filter is active, the toolbar shows a “Remove All” button.

1. Open the web client on a desktop browser (more on mobile below).
2. Log in as the root user (more on that below too).
3. Pick the library that has the missing items.
4. Open the filter dropdown at the top of the library and set it to Issues.
5. The toolbar now shows a red Remove All N items button. Clicking it deletes every item that’s flagged. You can also click into a single item and use Edit, then Delete, if you want to remove them one at a time.

If your list mixes real missing items with files that are temporarily unmounted, do not use Remove All. Filter to the actual deletions, or step through them individually.

”There’s no delete button”, it’s a permission

A few users on the issue thread thought the delete button was broken or removed. It isn’t. By default, only the root user has the delete permission. The user model spells this out in server/models/User.js:

return {
  download: true,
  update: type === 'root' || type === 'admin',
  delete: type === 'root',
  upload: type === 'root' || type === 'admin',
  // ...
}

So:

• root can delete library items.
• admin cannot, by default. You have to grant the delete permission explicitly under Settings, Users.
• user cannot either, same fix.

The button silently doesn’t render when the permission is missing, which is why the UI looks broken. LiamWilkinson noted this on the tracking issue after digging into the source. If you’re logged in as your everyday admin account and don’t see Remove All, that’s why. Switch to the root user, or grant the admin account the delete permission.

The mobile gotcha

The Issues filter, the Remove All button, and the per-item delete all live in the web client at desktop width. On a phone-width browser they are not reachable: the toolbar collapses, the navigation rearranges, and there is no equivalent in the iOS or Android apps. The matching feature request is open as #1379 and has not been picked up. Your options are:

• Use a real computer to do the cleanup.
• Or, on your phone browser, open the browser menu and request the desktop site, then rotate to landscape. The web client lays out enough of the toolbar to reach the filter and the button. This works but is fiddly.

If Remove All looks wrong, sanity-check first

Before you click Remove All, double-check that the items it would delete are actually the ones you removed. Two cases produce false positives:

• A volume path changed. If your Docker audiobooks volume is missing or pointed at the wrong host directory, every item in that library will look missing. Fix the path and rescan before doing any deletes. The server reboot crash post covers a related volume-mount foot-gun.
• A network share is unmounted. Same idea on NAS setups. If your CIFS mount isn’t up at boot, the whole library is “missing” until it remounts.

Open one of the items and look at the path. If the path is correct and the file genuinely isn’t there, you can clear it. If the path looks wrong, fix the mount first.

There’s no setting for “auto-delete on rescan”

There has been a long discussion on #3765 about adding a toggle to auto-remove items when their files go missing. Per advplyr the holdup is keeping that safe across filesystems that can’t reliably distinguish a rename from a delete plus a re-add. The issue is still open as an enhancement; if you want it, add a thumbs up to the original post rather than commenting “+1”.

Affected versions

Confirmed on v2.34.0. The “Remove All” flow has been there since v2.0.3, the permission default has always been root-only delete, and the mobile gap predates the issue itself. None of this is a regression, just behavior that catches new admins off-guard.

If you also see phantom items in SoundLeaf after cleaning them up server-side, pull-to-refresh the library tab and they’ll drop off.

Happy listening, Hemant