Scheduled downloads failing(?) resulting in "Missing" videos

[JackCuthbert]

Since upgrading to the dev-latest as suggested from #426 to resolve a permissions error the scheduled downloads will work just fine for ~2 days, then at some point videos will just stop getting downloaded (it's happened twice now). Upon checking the UI these missed downloads end up in a "Missing" state. This implies they have been attempted to download, or they did get downloaded at some point but they didn't make it all the way through the from the /tmp directory to the final location at YOUTUBE_OUTPUT_DIR.

Starting a download of the missing video from the channels view results in an error code 1, the error message appears to be related to a missing file or path/dir? A restart of the container (with --force-recreate) usually resolves it. (Quick edit: My VM this runs on is rebooted nightly for a backup, I suspect that's unrelated as it takes a couple days for this issue to occur).

I'm raising an issue as this is a new and different problem to the permissions issue in #426. If it's known (or related to my configuration?) feel free to close it, I couldn't find anything via searching 🙏.

App Configuration

I have auto delete set to 2 weeks, all the missing videos are less than 3 days old and a preview of the auto delete shows the correct ones.

Configuration Files

I'm using a /tmp dir mounted on the VM running YouTarr (over USB passthrough from Proxmox) and the output is an NFS mount. This is done to reduce the network load and reliability of my setup/servers.

config/config.json changes:

{
    // ...snip
    "useTmpForDownloads": true,
    "tmpFilePath": "/tmp/youtarr/downloads",
    // ...snip
}

docker-compose.yml changes:

diff --git a/docker-compose.yml b/docker-compose.yml
index 1122b84..acc8ff0 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -82,6 +82,7 @@ services:
       - "3087:3011"
     volumes:
       - ${YOUTUBE_OUTPUT_DIR}:/usr/src/app/data
+      - /mnt/usb/youtarr:/tmp/youtarr
       - ./server/images:/app/server/images
       - ./config:/app/config
       - ./jobs:/app/jobs

[JackCuthbert]

Happened again! I have logs this time, redacted video ID and video name for privacy :) A container restart resolved it again.

This seems to imply more permission issues though I'm not convinced considering a restart fixes it with no other changes to permissions or directories.

Overnight failure:

youtarr  | [2026-02-15 21:01:17.505 +0000] INFO: [2026-02-15 21:01:17.503 +0000] INFO: [Post-Process] Moving video directory {"from":"/tmp/youtarr/downloads/VIDEO_PATH_AND_TITLE - VIDEO_ID","to":"/usr/src/app/data/VIDEO_PATH_AND_TITLE - VIDEO_ID"} {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.507 +0000] INFO: [2026-02-15 21:01:17.506 +0000] ERROR: [Post-Process] ERROR during move operation {"videoDirectory":"/tmp/youtarr/downloads/VIDEO_PATH_AND_TITLE - VIDEO_ID"} {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.507 +0000] INFO: error: { {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.507 +0000] INFO: "errno": -13, {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.507 +0000] INFO: "code": "EACCES", {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.507 +0000] INFO: "syscall": "mkdir", {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.507 +0000] INFO: "path": "/usr/src/app/data/VIDEO_PATH_AND_TITLE - VIDEO_ID" {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.507 +0000] INFO: } {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.507 +0000] INFO: [2026-02-15 21:01:17.506 +0000] ERROR: [Post-Process] Files remain in temp location {"videoDirectory":"/tmp/youtarr/downloads/VIDEO_PATH_AND_TITLE - VIDEO_ID"} {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:17.513 +0000] INFO: ERROR: Command returned error code 1
youtarr  |  {"source":"yt-dlp-stderr"}
youtarr  | [2026-02-15 21:01:17.514 +0000] WARN: Error detected in stderr {"currentVideoId":"VIDEO_ID"}
youtarr  |     error: "Command returned error code 1"
youtarr  | [2026-02-15 21:01:17.514 +0000] INFO: Recorded video failure from stderr {"youtubeId":"VIDEO_ID"}
youtarr  |     error: "Command returned error code 1"
youtarr  | [2026-02-15 21:01:17.521 +0000] INFO: [download] Finished downloading playlist: PLAYLIST_NAME - Videos {"source":"yt-dlp"}
youtarr  | [2026-02-15 21:01:18.262 +0000] WARN: Video file not found after retries {"videoId":"VIDEO_ID","expectedPath":"/usr/src/app/data/VIDEO_PATH_AND_TITLE - VIDEO_ID/VIDEO_PATH_AND_TITLE [VIDEO_ID].mp4"}
youtarr  | [2026-02-15 21:01:18.262 +0000] WARN: Download failed {"youtubeId":"VIDEO_ID","hasVideoFile":null,"hasAudioFile":null}
youtarr  |     error: "Command returned error code 1"

After running the download again for the "Missing" file:

youtarr  | [2026-02-16 02:26:04.738 +0000] INFO: [download] VIDEO_ID: has already been recorded in the archive {"source":"yt-dlp"}
youtarr  | [2026-02-16 02:26:05.473 +0000] WARN: Video file not found after retries {"videoId":"VIDEO_ID","expectedPath":"/usr/src/app/data/VIDEO_PATH_AND_TITLE - VIDEO_ID/VIDEO_PATH_AND_TITLE [VIDEO_ID].mp4"}
youtarr  | [2026-02-16 02:26:05.473 +0000] WARN: Download failed {"youtubeId":"VIDEO_ID","hasVideoFile":null,"hasAudioFile":null}
youtarr  |     error: "Media file not found or incomplete"

[dialmaster]

I believe the root problem is a cross-filesystem move from USB to NFS. When the NFS mount goes stale, fs.move() fails with EACCES.
The file is DOWNLOADED to the /tmp/ location, but then Youtarr can't move it to the destination.
Restarting Youtarr fixes the stale NFS mount, but then since yt-flp recorded the "successful" download in the archive, you have the issue where you can't "re-download" it because yt-dlp thinks it was already downloaded.

I am making some defensive fixes on my end, but the main issue is your NFS mount getting stale in docker (not a Youtarr bug per se).
I found evidence of this issue elsewhere when I did a google search for things like "docker NFS stale" etc...

I think changing your NFS mount options to something like this would fix things:
server:/export /mnt/nfs-output nfs hard,intr,actimeo=3,timeo=300,retrans=5 0 0

• hard retries NFS operations indefinitely instead of failing with EACCES (the default soft gives up)
• intr allows signals to interrupt hung NFS ops (so container stop isn't blocked)
• actimeo=3 refreshes NFS attribute cache every 3 seconds (prevents stale metadata; default is 60s which is too aggressive for this use case)
• timeo=300,retrans=5 30-second timeout with 5 retries before declaring failure

OR you could try modifying your docker-compose.yml to use a Docker native NFS volume. Something like this:

Currently your docker-compose.yml uses a bind-mount:

volumes:
  - ${YOUTUBE_OUTPUT_DIR}:/usr/src/app/data   # bind-mounts host NFS dir

Replace with a named NFS volume:

services:
  youtarr:
    volumes:
      - youtube-data:/usr/src/app/data        # use named NFS volume instead
      - ./server/images:/app/server/images
      - ./config:/app/config
      - ./jobs:/app/jobs

volumes:
  youtube-data:
    driver: local
    driver_opts:
      type: nfs
      o: addr=YOUR_NFS_SERVER_IP,hard,intr,nfsvers=4,actimeo=3
      device: ":/path/to/your/nfs/export"

This way Docker mounts NFS directly into the container... no host mount in the middle to go stale.

[JackCuthbert]

Curious! I guess the time it takes for certain operations in Youtarr exceed these defaults which haven't caused issues for me elsewhere 🤔. I've made the change to my NFS mounts and I'll report back if this happens again.

[dialmaster]

Some additional things to help alleviate this will go out with the next release, see: #440
Closing this issue