Chris wrote:
Thanks, that confirms Tdarr is running through SparkBox 1.6.881 on the Dell, with the separate worker planned for Ubuntu. SparkBox sets up the Tdarr server and its built-in node; the module doesn't provide a SparkBox control for adding another machine. A remote node needs Tdarr's own setup, and I can’t verify its current official steps from here, so I don’t want to guess at commands. Before we choose a safe route, would the NUC be able to access the same library folders at the same path as the Dell, or would it need to process files stored only on the NUC? Please don’t format the external SD or change the library yet.
kiltmann wrote:
I'm using Claude to help with this, as follows. Ignore the Portainer comments as I am using Dockhand. I thought I would post the whole thread so you can check it. The NUC needs three things: access to the media files at the same path the Tdarr server sees them, a shared transcode cache, and a network connection to the Tdarr server on port 8266. The steps below set that up with NFS for the files and Docker for the node. Before you start, collect four things from the server The server's IP address. On the server, run hostname -I. The first address listed is the one you need. I'll call it SERVERIP below. Tdarr's volume mappings. In Portainer, open the Tdarr container and go to Volumes. Write down each host path → container path pair. For example, you might see /mnt/storage → /media and some cache folder → /temp. The NUC must use the exact same container paths, or jobs will fail with "file not found." Tdarr's published ports. Check that port 8266 is listed. That's the port nodes connect to. If only 8265 (the web UI) is published, add 8266 → 8266 and redeploy. Your user and group IDs. On the server, run id. Note the uid and gid numbers, which are usually 1000. Use the same numbers on the NUC so file permissions line up. Part 1: Share the storage from the server (run these on the server) Install the NFS server: sudo apt install nfs-kernel-server Create a cache folder inside the pool. Both machines must see the transcode cache, and putting it here means one share covers everything: sudo mkdir -p /mnt/storage/tdarrcache sudo chown 1000:1000 /mnt/storage/tdarrcache Replace 1000:1000 with your uid:gid if they're different. 3. Open the exports file: sudo nano /etc/exports Add this line at the bottom: /mnt/storage 192.168.4.XX(rw,sync,nosubtreecheck,fsid=1) The fsid=1 is required. Your pool is mergerfs, and NFS won't export it reliably without that option. Save with Ctrl+O, Enter, then exit with Ctrl+X. 4. Apply the change and start NFS: sudo exportfs -ra sudo systemctl enable --now nfs-server If the firewall is on (check with sudo ufw status), allow the NUC through: sudo ufw allow from 192.168.4.XX Keep SnapRAID from tracking the constantly changing cache files. Open the config: sudo nano /etc/snapraid.conf Add: exclude /tdarrcache/ Without this, every sync and scrub will churn on temporary transcode files. 7. Point the server's Tdarr cache at the new folder. In Portainer, edit the Tdarr container's cache volume so the host path is /mnt/storage/tdarrcache. Keep the container side the same, such as /temp. Then redeploy. Do this when no transcodes are running. Part 2: Mount the share on the NUC (run these on the NUC) Install the NFS client and create the mount point: sudo apt install nfs-common sudo mkdir -p /mnt/storage Test the mount by hand: sudo mount -t nfs SERVERIP:/mnt/storage /mnt/storage ls /mnt/storage You should see your media folders. If you do, unmount it with sudo umount /mnt/storage. 3. Make the mount permanent. Open the mount table: sudo nano /etc/fstab Add: SERVERIP:/mnt/storage /mnt/storage nfs defaults,netdev,nofail,x-systemd.automount 0 0 The nofail option keeps the NUC from hanging at boot if the server is down. 4. Reload and mount: sudo systemctl daemon-reload sudo mount -a Check that the NUC can write to the cache. You should see no error: touch /mnt/storage/tdarrcache/test && rm /mnt/storage/tdarrcache/test Part 3: Install Docker on the NUC Install Docker with the official script: curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker $USER Log out and back in so the group change takes effect. Confirm the NUC's Intel GPU is visible to Linux: ls /dev/dri You want to see renderD128. Part 4: Run the Tdarr node Create folders for the node and its compose file: sudo mkdir -p /opt/tdarr-node/configs /opt/tdarr-node/logs mkdir -p ~/tdarr-node && nano ~/tdarr-node/docker-compose.yml Paste the following. Adjust SERVERIP, the uid/gid numbers, and the container-side paths, meaning the part after the colon, so they match what you wrote down from the server. yaml services: tdarr-node: image: ghcr.io/haveagitgat/tdarrnode:latest containername: tdarr-node restart: unless-stopped networkmode: host environment: - TZ=America/Indiana/Indianapolis - PUID=1000 - PGID=1000 - UMASKSET=002 - nodeName=NUC - serverIP=SERVERIP - serverPort=8266 - inContainer=true - nodeType=mapped volumes: - /opt/tdarr-node/configs:/app/configs - /opt/tdarr-node/logs:/app/logs - /mnt/storage:/media - /mnt/storage/tdarrcache:/temp devices: - /dev/dri:/dev/dri Start the node and watch its log: cd ~/tdarr-node docker compose up -d docker logs -f tdarr-node You want a line saying it connected to the server. Press Ctrl+C to stop watching. Part 5: Turn it on in Tdarr Open the Tdarr web UI. NUC should now appear in the Nodes section. Set its worker counts (start with 1 GPU transcode worker), and make sure your plugin or flow uses QSV so it actually uses the NUC's GPU. You may also want to lower the server's own worker count so the server isn't competing with the NUC. If something doesn't work Node never appears in the UI: from the NUC, run nc -zv SERVERIP 8266. If it fails, port 8266 isn't published on the server, or a firewall is blocking it. Jobs fail with "file not found": the container paths on the NUC don't match the server's. Compare the volume mappings side by side. "Permission denied" errors: the PUID/PGID on the NUC don't match the owner of the files on the server. One caveat: all of Part 1 requires a terminal on the server. If Tdarr lives on the TomSparkBox install where you only have dashboard access, tell me which machine actually holds /mnt/storage and runs the Tdarr container, and I'll adjust the steps. tdarr is running through tom sparks' sparkbox on the main server. Good. That mostly affects how you make changes on the server side. The NFS steps on the Ubuntu host (Part 1) still apply because SparkBox runs on top of that same host. The difference is that SparkBox manages the Tdarr container, so you'll check and edit it differently, and you can avoid moving its cache at all. Step 1: Look at SparkBox's Tdarr container in Portainer Open Portainer and go to Containers. Click the Tdarr container (probably named sb-tdarr or similar). Write down four things: Volumes: each host path → container path. You need the media mapping and the cache/transcode mapping (often /temp or /transcodecache on the container side). Network: whether it says something like sbproxy / bridge, or container:sb-gluetun. Ports: whether 8266 is listed with a host port. Stack: at the top, whether it says it belongs to a stack, and which one. Step 2: Make sure port 8266 is reachable from the LAN The NUC talks to Tdarr directly on port 8266. NPM and the Cloudflare tunnel only cover the web UI, so they don't help here. If 8266 is already published with a host port, nothing to do. If it isn't, and the container is in a stack: Go to Stacks, open that stack, and click Editor. Under the Tdarr service's ports: section, add - "8266:8266". Click Update the stack. Edit the stack rather than the container directly. Editing only the container gets undone the next time the stack is redeployed. If the network is container:sb-gluetun, the port has to be published on the gluetun service instead, the same way. Honest caution: SparkBox may rewrite its stacks when you update or reinstall apps through its dashboard. After any SparkBox update, check that 8266 is still published. If the NUC suddenly drops offline in Tdarr, check this first. Step 3: Share the existing cache instead of moving it Skip step 7 of Part 1 (repointing the server's cache). Leaving SparkBox's settings alone is safer. If the cache host path is already under /mnt/storage, the single NFS export from Part 1 covers it. You can also skip creating /mnt/storage/tdarrcache. Add the SnapRAID exclude for whatever folder it actually uses. If the cache is somewhere else (for example /opt/docker/...), share that folder too: On the server, add a second line to /etc/exports. Replace /path/to/cache with the real host path: /path/to/cache 192.168.4.XX(rw,sync,nosubtreecheck) Run sudo exportfs -ra. On the NUC, create the same folder with sudo mkdir -p /path/to/cache, and add a matching fstab line: SERVERIP:/path/to/cache /path/to/cache nfs defaults,netdev,nofail,x-systemd.automount 0 0 Run sudo systemctl daemon-reload && sudo mount -a. Step 4: Match the paths in the NUC's compose file In the Part 4 compose file, change the two volume lines so the right-hand side (container path) is identical to what SparkBox's Tdarr container uses. For example, if SparkBox maps /mnt/storage → /data and /opt/docker/tdarr/cache → /temp, the NUC needs: yaml - /mnt/storage:/data - /opt/docker/tdarr/cache:/temp Step 5: Test the connection, then start the node From the NUC, run: nc -zv SERVERIP 8266 If it says "succeeded," run docker compose up -d as in Part 4. The NUC should then appear in Tdarr's Nodes list. If you paste what Portainer shows for the Tdarr container's volumes, network, and ports, I'll give you the exact lines to use.
Chris wrote:
I’m sorry—I should have checked the SparkBox setup against your proposed steps instead of leaving you to validate them. In SparkBox 1.6.881, Tdarr already publishes port 8266, maps the library to the container path /data, and mounts its configured cache at /temp; that does not verify that the two machines should share one writable cache. Please don’t add the NFS exports, change SnapRAID, or edit/redeploy SparkBox’s Tdarr stack based on that recipe. One safe next check: in Dockhand, look only at the Tdarr container’s volume destinations on the Dell and tell me whether the library is mounted at /data and the cache at /temp (you can replace the host-side paths with [library] and [cache]). No passwords or full configuration. I can then help check the path match without changing anything. I’ve corrected our guidance so we don’t pass on the unverified shared-cache/NFS steps as requirements to the next person.