My question: root@DESKTOP-51RQN55:/mnt/c/Users/quint findmnt -T /mnt/z/media -o TARGET,SOURCE,FSTYPE,OPTIONS,PROPAGATION TARGET SOURCE FSTYPE OPTIONS PROPAGATION /mnt/z Z: 9p rw,relatime,aname=drvfs;path=Z:;symlinkroot=/mnt/,cache=0x5,access=client,msize=65536,trans=fd,rfd=3,wfd=3 private root@DESKTOP-51RQN55:/mnt/c/Users/quint sudo docker exec sb-jellyfin-media sh -c 'ls -la /data; mount | grep " /data "' total 8 drwxr-xr-x 2 root root 4096 Sep 3 22:50 . drwxr-xr-x 1 root root 4096 Sep 3 23:08 .. /dev/sdd on /data type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered) root@DESKTOP-51RQN55:/mnt/c/Users/quint sudo docker info | grep -E 'Operating System|Docker Root Dir' Operating System: Ubuntu 24.04.4 LTS Docker Root Dir: /var/lib/docker root@DESKTOP-51RQN55:/mnt/c/Users/quint SparkBox AI replied: That output nails it: - WSL sees Z: as a 9p/DrvFS mount. - It’s marked private. - Jellyfin sees /data as /dev/sdd, the empty directory that existed underneath the mount. So Docker is not receiving the Z: mount at all. Your library paths and MEDIAROOT=/mnt/z/media are fine. Don’t restart the stack again yet. This needs the WSL mount fixed so it exists in Docker’s mount namespace before Docker creates the bind mount. The Windows/WSL setup needs a persistent mount setup rather than a manually mounted mapped drive. Click Share …(reply truncated — full chat sent to Tom)
7 replies
Chris wrote:
Got it — this is an automatic acknowledgment from Chris. Your post is in the support queue, and we’ll get to it as soon as we can. Legend members receive priority replies. If you’d like faster support while helping fund the project’s goals and continued development, consider becoming a Legend backer. <!-- chris-support-queue-ack:v1 --
Chris wrote:
Thanks for pasting the WSL output. It shows the Windows Z: drive is visible inside WSL, while the Jellyfin container is currently seeing a different, empty data mount. I can’t safely prescribe a remount or Docker/Windows change from the partial transcript, and I don’t want you changing mount settings blindly. I’ve logged this and our team is investigating this. I’ll compare the WSL host path and SparkBox media bind next; please keep private keys, tokens, and full configuration files out of the thread.
QuintoneArmado wrote:
When in WSL it sees all my data just jellyfin doesnt see any. So i havent been able to use it at all. Spark box running on windows 11 media on UGREEN NAS
Chris wrote:
Thanks — that matches what the earlier output showed: the Z: drive is reachable inside WSL, but Jellyfin isn't reading from it. Inside the container, Jellyfin's /data folder is mapped from the Media Root location you set (MEDIAROOT), and right now that mapping is resolving to an empty folder on WSL's internal disk instead of your Z: drive. That's the mapped-drive case I have logged as a known gap, and there's no shipped fix for it yet — so let's try the safe supported path and confirm where it sits. Please run these two read-only checks in your WSL terminal and reply with only what they print: 1. ls /mnt/z/media — expected: the movie/TV folders you can see in Windows. 2. sudo grep -n "^MEDIAROOT" /opt/sparkbox/.env — expected: MEDIAROOT=/mnt/z/media (that one line only — please redact anything else the file prints). If both match, the safe next step is to recreate the media containers so they re-read the drive (sudo sparkbox restart media), then check sudo docker exec sb-jellyfin-media ls /data — expected: the same folders. If that still comes back empty, reply "still empty" along with those two outputs, and I'll set up the durable fix with you — pointing SparkBox at the UGREEN share directly from inside WSL, so it no longer depends on the Windows drive mapping.
QuintoneArmado wrote:
I’ve completely reinstalled I’ve redone everything I’ve remounted it is still empty is sees the the drive and somthing is telling them they are empty
Chris wrote:
Thanks for sticking with this. I know the reinstall/remount cycle is frustrating when it doesn't fix it. Before we try the workaround, I need to confirm: when you reinstalled, did you run these two exact commands in your WSL terminal? 1. ls /mnt/z/media 2. sudo grep -n "^MEDIAROOT" /opt/sparkbox/.env If you didn't run those, or if they showed something different from what I asked for, reply with what they printed. If they matched (the folder exists and MEDIAROOT=/mnt/z/media), and you still see it empty in Jellyfin, the issue is that the Z: drive mapping inside WSL is reaching SparkBox, but Docker's internal bind isn't picking it up. That's the mapped-drive case — and the supported fix is to mount the UGREEN NAS directly from inside WSL instead of through the Windows Z: drive. That's a different setup. Can you confirm: are you able to reach the UGREEN NAS directly from your WSL terminal (for example, if it's at an IP address, can you ping it)? If yes, I'll walk you through the direct mount.
Chris wrote:
You were right that the drive was there and something was hiding it. We found it: a drive you mount from the WSL terminal lands in a place Docker cannot see, so Jellyfin got an empty folder under the same name. Reinstalling could never change that. v1.6.705 fixes it: sparkbox up now replays the mount where Docker can see it, so no direct NAS mount is needed. In your WSL terminal: 1. sudo sparkbox upgrade 2. sudo sparkbox up Then open Jellyfin and check the library; the files should appear. If it is still empty, paste the output of sudo sparkbox up here and I will take it from there.