Summary
altmount's SAB-history endpoint returns status=Completed for items
whose reported path doesn't exist on disk, causing Sonarr/Radarr to
import-loop with FileNotFoundException until manually unstuck.
The endpoint already detects this condition and logs it:
level=WARN msg="sabnzbd history: reported path does not exist on disk"
item_id=17311
storage_path=/complete/shows-DUTCH/Doug.Unplugs.S01E01.DUTCH.2160p.WEB.H265-REMBRANDT-xpost
reported_path=/mnt/debrid/altmount-sym/complete/shows-DUTCH/Doug.Unplugs.S01E01.DUTCH.2160p.WEB.H265-REMBRANDT-xpost
But it still returns the item with the missing path and status=Completed. The ARRs enqueue the item and fail import.
Environment
- altmount image:
ghcr.io/javi11/altmount:pinned-20260513
- Import strategy:
SYMLINK, Import.ImportDir = /mnt/debrid/altmount-sym
- FUSE mount:
/mnt/altmount (rclone)
- Sonarr/Radarr use altmount as the SAB-compatible download client
What's actually happening (verified)
Earlier I framed this as "altmount serves release B when release A was grabbed". That was wrong, there is no rename or content drift.
Verified across 10 currently-WARN'd items:
| Check |
Result |
FUSE file exists at MountPath + storage_path |
yes, 10/10 |
Symlink exists at ImportDir + storage_path |
no, 10/10 |
| FUSE serves a different release than storage_path advertises |
no, 0/10 |
All 10 items have FUSE mtime between May 17 and May 19 03:57, before a permission issue on ImportDir was fixed locally. After the fix, about 5,955 symlinks were created on the day of the fix and ~1,300 per day since, so new imports create symlinks fine. These 10 are legacy items where symlink creation failed at import time and was never retried.
altmount's queue table keeps them with status=Completed, and calculateHistoryStoragePath returns the (non-existent) symlink path on every SAB-history poll. There is no self-healing path: the symlink never gets created, the item is never marked failed, and the ARRs see "Completed, path P" forever.
Expected
When calculateHistoryStoragePath detects the path is missing:
- (minimal) Return
status=Failed for that slot in the SAB-history response, with a fail message pointing at the missing path. The ARR removes it cleanly through its normal failed-download path.
- (better) Attempt to recreate the symlink first, then fall through to (1) if creation still fails.
(1) alone is enough to stop the loop. Happy to send a PR for (1).
Repro
- Configure altmount with
Import.ImportStrategy=SYMLINK and an Import.ImportDir separate from MountPath.
- Cause symlink creation to fail at import time (e.g. wrong perms on
ImportDir).
- Watch the affected items stay at
status=Completed with reported_path on ImportDir even after perms are fixed. Each SAB-history poll fires the WARN; each ARR-side import fires FileNotFoundException.
Workaround used locally
10-minute cron: find /mnt/debrid/altmount-sym -xtype l -delete on the symlink farm, plus per-ARR queue cleanup that blocklists the release and removes it. Doesn't fix the underlying altmount queue entry, just keeps it from saturating the ARR queues.
Related
Summary
altmount's SAB-history endpoint returns
status=Completedfor itemswhose reported path doesn't exist on disk, causing Sonarr/Radarr to
import-loop with
FileNotFoundExceptionuntil manually unstuck.The endpoint already detects this condition and logs it:
But it still returns the item with the missing path and
status=Completed. The ARRs enqueue the item and fail import.Environment
ghcr.io/javi11/altmount:pinned-20260513SYMLINK,Import.ImportDir = /mnt/debrid/altmount-sym/mnt/altmount(rclone)What's actually happening (verified)
Earlier I framed this as "altmount serves release B when release A was grabbed". That was wrong, there is no rename or content drift.
Verified across 10 currently-WARN'd items:
MountPath + storage_pathImportDir + storage_pathAll 10 items have FUSE mtime between May 17 and May 19 03:57, before a permission issue on
ImportDirwas fixed locally. After the fix, about 5,955 symlinks were created on the day of the fix and ~1,300 per day since, so new imports create symlinks fine. These 10 are legacy items where symlink creation failed at import time and was never retried.altmount's queue table keeps them with
status=Completed, andcalculateHistoryStoragePathreturns the (non-existent) symlink path on every SAB-history poll. There is no self-healing path: the symlink never gets created, the item is never marked failed, and the ARRs see "Completed, path P" forever.Expected
When
calculateHistoryStoragePathdetects the path is missing:status=Failedfor that slot in the SAB-history response, with a fail message pointing at the missing path. The ARR removes it cleanly through its normal failed-download path.(1) alone is enough to stop the loop. Happy to send a PR for (1).
Repro
Import.ImportStrategy=SYMLINKand anImport.ImportDirseparate fromMountPath.ImportDir).status=Completedwithreported_pathonImportDireven after perms are fixed. Each SAB-history poll fires the WARN; each ARR-side import firesFileNotFoundException.Workaround used locally
10-minute cron:
find /mnt/debrid/altmount-sym -xtype l -deleteon the symlink farm, plus per-ARR queue cleanup that blocklists the release and removes it. Doesn't fix the underlying altmount queue entry, just keeps it from saturating the ARR queues.Related
*.mkv_<id>filename-suffix variant. Adjacent, different fix surface.