On my NAS setup I've found issues realted to the rclone cache. Files consistently disappear from Plex. It isnt strictly an NZBDAV issue, but something to do with the way plex caches the media library.

TLDR: Try Restarting Plex (container) and rescanning. It works to fix it because it forces Plex to throw away its stale “files are missing” view and rebuild it from the now‑healthy rclone/nzbDAV mount, while the symlinks on disk never actually disappeared.

Longer AI transcript from me mucking around with it:

What you’re seeing is two separate layers interacting:

The filesystem layer (rclone + nzbDAV + symlinks).
Plex’s in‑memory and database view of that filesystem.

Restarting Plex and rescanning doesn’t “recreate” symlinks; it just makes Plex look at them properly again after the underlying mount has changed.

What actually disappears (and what doesn’t)
The symlink entries under /data/media/tv/... on the NAS do not disappear. They’re still there, as ls inside the Plex container keeps showing the Ahsoka.S01E01... -> /mnt/nzbdav/.ids/... links.

The target files in .ids are sometimes missing right after you remount or when the mount/cache is in a weird state, but in your latest check you confirmed they exist again.

What “disappears” is Plex’s belief that those files exist, not the symlinks themselves.

So the “disappearing” is in Plex’s internal index, not in the symlink layer on disk.

Why restarting Plex + rescan fixes it
When the rclone/nzbDAV side hiccups (mount drops, cache cleared, .ids empty for a while):

Plex tries to access the symlink target.

It follows /data/media/tv/.../Ahsoka.S01E01.mkv → /mnt/nzbdav/.ids/....

At that moment, the target path 404s (mount down, .ids empty, or rclone error).

Plex marks that item as unavailable / missing in its database.

If this happens for lots of items, the whole library view can appear empty or almost empty.

When the mount/cache is later fixed and .ids has files again, Plex does not automatically re‑trust those paths.

A plain “Scan Library Files” often just checks for new files, and it may skip items it already thinks are missing, especially on FUSE mounts.

When you do your “fix” sequence:

bash /volume1/docker/rclone_mount.sh

Ensures rclone is cleanly remounted and .ids is readable again.

docker exec ... ls -al /data/media/... and ls -al /volume1/data/mnt/nzbdav/.ids/...

Forces the OS and container to actually touch those paths and prove they’re there.

docker restart plexnzb

Drops Plex’s in‑memory state and reopens all its library paths fresh.

On startup, Plex rereads the library root and rebuilds its internal list of “what exists”.

Then Scan Library Files

Now runs against a stable mount with valid targets, so items are re‑seen as available.

So the key is: Plex has to be restarted after the mount is fixed, otherwise it keeps believing its old “these files are gone” view and a scan alone can be too lazy to correct it.

What makes things look like symlinks “disappear”
From your perspective, it feels like symlinks vanish because:

Plex’s UI hides items marked as missing/unavailable, so the library looks empty.

When rclone/nzbDAV had .ids empty or the mount down, every symlink resolved to a dead path, so Plex quietly marked many items as missing.

Later, even when .ids is back, Plex doesn’t revisit those paths aggressively until you restart it.

But if you check on the NAS:

bash
ls -al /volume1/data/media/tv/Ahsoka/Season\ 1
you’ll see the symlinks are still there; Plex just wasn’t trusting or re‑evaluating them.

Why your environment is particularly prone to this
You’re using rclone FUSE mount → nzbDAV .ids → symlinks → Plex in Docker.

Any of these events can temporarily make every symlink look broken:

NAS reboot where rclone doesn’t come up cleanly.

Your old script clearing /volume1/data/mnt/nzbdav/*.

rclone crash under Plex scan load.

During those windows, Plex tries to read the files, fails, and updates its DB to “these are gone”.

When you later fix the mount, Plex’s DB is now out of sync with reality until you restart Plex and rescan.

Files dissappearing #304

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions