Hi - So I have installed TomSparkBox and loving it! I am totally new to ubuntu and using search engine AI I was able to incorporate my current library in addition to the automation part. I created a new data file inside the current Media Root "/opt/sparkbox/data/media/remotelibrary" and then I created an NFS Mount to that remotelibrary ... rebooted and nothing was working. But when I used the Dir command I could see the remote library from my NAS....I did reboot on Jellyfin and BOOM! it all worked. My new media root is over NFS to my Library location. My Old media moved to the new TV and Movies and see everything over SMB and the NAS. My issue is after restarting, is sparkbox starts probably seconds before the NFS is mounted so Jellyfin shows nothing until after I do a Jellyfin restart from my SparkBox Dashboard. I attempted to edit sudo systemctl edit docker.service but seems to not work in this situation. Do you have a suggestion to get either the entire sparkbox to load a few seconds after, or have a delay on the Jellyfin only?
8 replies
tomspark wrote:
Thanks for the fstab and findmnt — exactly what was needed. Here's what's going on: your NFS line uses bg and nofail, which are "don't hold up boot" options. They let the system carry on before the share is fully ready, so even the mount-dependency trick can wave the containers through a beat too early — which is why Jellyfin still comes up empty. This is the boot-timing gap Tom's already working on in the product itself, and your exact setup is a perfect test case, so I've passed it straight to him for the verified fix rather than have you keep hand-editing boot files. In the meantime your dashboard Jellyfin restart is a fine stopgap — not elegant, but it won't hurt anything. I'll follow up here when the real fix lands.
Chris wrote:
You are right about the race; an arbitrary sleep is not the best fix. Docker must wait for that exact NFS mount before it starts the containers. Run sudo systemctl edit docker.service and add: [Unit] RequiresMountsFor=/opt/sparkbox/data/media/remotelibrary After=network-online.target remote-fs.target Save, then run sudo systemctl daemon-reload and reboot once. That uses the real mount dependency instead of guessing a delay. If it still starts empty, reply with the single NFS line from /etc/fstab and the output of findmnt /opt/sparkbox/data/media/remotelibrary; redact credentials if your mount options contain any. I confirmed the generated SparkBox boot unit only waits for networking today, so I am preparing a product-side fix.
Leo20 wrote:
Hello Chris, It still starts empty. Here is NFS line from fstab: 10.10.10.60:/volume1/library/sparkbox /opt/sparkbox/data/media/remotelibrary nfs bg,nofail,soft,timeo=30,retrans=1,netdev 0 0 Here is the output of findmnt: TARGET SOURCE FSTYPE OPTIONS /opt/sparkbox/data/media/remotelibrary 10.10.10.60:/volume1/library/sparkbox nfs4 rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,soft,fatalneterrors=none,proto=tcp,timeo=30,retrans=1, Thank you,
Chris wrote:
The real fix landed — Tom shipped it today in v1.6.444, built from the exact fstab line you posted. One important thing first: please take out that RequiresMountsFor= line I had you add. Because your mount is nofail, it hard-requires the share, and Tom's reboot test measured what happens when the NAS is unreachable — docker.service doesn't start at all. Every container down, not just Jellyfin. That one's on me. Run sudo systemctl edit docker.service, delete the lines you added, save, then sudo systemctl daemon-reload. After that, sudo sparkbox upgrade installs ordering that waits for your share without ever gating Docker on it.
Leo20 wrote:
Chris, I can confirm the 'remotelibrary' loads before the jellyfin container/docker service resulting with my NAS Library being automatically mounted to Jellyfin. Thank you so much!
Chris wrote:
That is the confirmation Tom was waiting on for this one — share mounts first, Jellyfin second, library there without you touching it. Thanks for staying with it, and for posting your fstab line; that is what the fix was actually built from. One last thing while you are in there: double-check the RequiresMountsFor lines are gone from sudo systemctl edit docker.service. The shipped ordering handles that job now, and leaving the old lines in place is the part that can stop Docker entirely if the NAS is ever slow or unreachable at boot. If that file is already empty, you are done.
Leo20 wrote:
I actually decided to leave the requiresmountfor lines because in my scenario there is no need to load docker or jellyfin if my NAS is offline. There will be no location to Save media and there will be no library to Stream from. If SparkBox starts with the NAS offline, once I bring the NAS is online I would still need to reboot the server or manually restart services. If you have any other points to support removing the requiresmountfor lines, I would like to consider them. I currently have these lines. [Unit] Requires=remote-fs.target After=remote-fs.target RequiresMountsFor=/opt/sparkbox/data/media/remotelibrary ConditionPathIsMountPoint=/opt/sparkbox/data/media/remotelibrary Thank you,
Chris wrote:
Good pushback — you've actually found a gap in what I told you, not the other way round. Here's the part I left out: after v1.6.444's own wait-for-mount step times out (2 minutes), SparkBox starts everything anyway, NAS or no NAS, empty library included. So for what you want — nothing running without the share — your RequiresMountsFor lines are the only thing actually doing that job right now. Keep them. Just keep an eye on it if the mount is ever flaky rather than fully offline, since that combination can be less forgiving than a clean online/offline split.