Hello again, I'm back, after running into many issues trying to run TomSparkBox on my Synology NAS within a Linux VM, I've recently purchased a Lenovo m720q with 16GB ram and 256GB storage, installed ProxMox and created a VM to run TomSparkBox for simplified arr apps. Installation went pretty well, and it seems to be running well, but the media storage comes up as almost full, which tells me that it's still pointing at the ProxMox VM that has 32GB allocated as it shows the disk is 86% full 23GB / 28GB for the system stats, and on the Media card on the dashboard, it shows 6.5GB free. In TomSparkBox server config - Media Root I have the following value: "/volume1/arr-data", which should connect to my Synology NAS where I've created the arr-data file share with permissions to allow access to the IP of the VM where TomSparkBox is installed, but the downloaded file never shows up on the NAS. Following the documentation on how to set the media root, I ran... sudo sed -i 's|^MEDIAROOT=.|MEDIAROOT=/volume1/arr-data/media|' /opt/sparkbox/.env and get... sed: can't read /opt/sparkbox/.env: No such file or directory Any recommendations on what I'm missing to fix the Media root and make sure bittorrent saves the downloaded files to the NAS media folder? Thank you!
11 replies
Chris wrote:
The key distinction is that putting /volume1/arr-data in Media Root does not mount the Synology share into your Proxmox VM; the VM must already have that share mounted at that Linux path, or downloads will land on the VM's own disk instead. The system-disk and Media-card free-space figures do not confirm that the NAS is mounted. Please run this read-only check inside the Linux VM and share its output: findmnt -T /volume1/arr-data -o SOURCE,FSTYPE,TARGET. If it reports the VM's root filesystem (or no mount), the share is not mounted there; if it reports a network filesystem, we can check the SparkBox/container path next. The /opt/sparkbox/.env edit failed because that file is not at that location on your VM, so please don't try another direct .env edit yet.
mtechnic wrote:
The "findmnt -T /volume1/arr-data -o SOURCE,FSTYPE,TARGET" command returns nothing when SSH'd into the VM running TomSparkBox. Can we look at logs on TomSparkBox to understand why it's not seeing the mount?
Chris wrote:
Thanks — that blank result doesn't tell us whether the path is absent or the command reported an error. TomSparkBox logs can't mount the NAS share; the VM must see it first. From SSH inside the Linux VM, please rerun findmnt -T /volume1/arr-data -o SOURCE,FSTYPE,TARGET and paste everything it prints, including any error text. If it prints nothing again, please also say whether /volume1/arr-data exists in the VM. A network-filesystem result (such as cifs or nfs) means we can then check SparkBox's container path; otherwise we need to resolve the VM mount first. Please don't edit .env or change permissions yet.
mtechnic wrote:
admin-jason@arr:~$ findmnt -T /volume1/arr-data -o SOURCE,FSTYPE,TARGET SOURCE FSTYPE TARGET /dev/mapper/ubuntu--vg-ubuntu--lv ext4 / Looks like /volume1/arr-data is not mounted. Can you help with the mount command?
Chris wrote:
Yes—the output confirms that this path currently resolves to the VM's own root filesystem, not a mounted NAS share. The right mount command depends on whether the Synology share is being offered over NFS or SMB, so I don't want to guess and give you a command that won't work. As the next step, please tell me which of those two protocols you intend to use for this share; don't post any passwords or other credentials. Then I can give you the matching mount check and command for the Ubuntu VM.
mtechnic wrote:
The Synology share is using NFS
Chris wrote:
NFS it is — here are the exact steps. Your output shows /volume1/arr-data is just an ordinary folder on the VM's own disk: typing the Synology's path into Media Root never reaches the NAS, so we mount the share onto that exact folder and SparkBox's Media Root can stay as it is. 1. On the Synology (DSM): Control Panel → File Services → NFS → tick Enable NFS service → Apply. Then Control Panel → Shared Folder → select arr-data → Edit → NFS Permissions → Create: Hostname or IP = your VM's IP address, Privilege = Read/Write, Squash = Map all users to admin (so your apps can write there without permission errors) → Save. 2. In the VM, over SSH, one line at a time (replace NAS-IP with your Synology's IP address): 1. sudo apt-get install -y nfs-common 2. sudo mv /volume1/arr-data /volume1/arr-data.vm-copy 3. sudo mkdir -p /volume1/arr-data 4. echo 'NAS-IP:/volume1/arr-data /volume1/arr-data nfs defaults,netdev,nofail 0 0' | sudo tee -a /etc/fstab 5. sudo mount -a 6. findmnt -T /volume1/arr-data -o SOURCE,FSTYPE,TARGET Line 2 moves aside whatever SparkBox already downloaded onto the VM's disk, so nothing gets hidden under the mount; it stays in /volume1/arr-data.vm-copy and you can copy it onto the share later. The fstab line (with nofail) makes the share come back after every reboot. Line 6 should now show NAS-IP:/volume1/arr-data with FSTYPE nfs or nfs4 instead of ext4 on /. If it does, run this so the apps pick up the share (they only see what was mounted when they started): sudo sparkbox restart media Then sudo sparkbox doctor → the [Media Storage] section should show your NAS's free space and that your apps can write there. If mount -a or the findmnt line shows an error instead, paste it here (no passwords) and we'll take it from there. About the .env edit from before: you don't need it — the Media Root box in Server Config does the same thing.
mtechnic wrote:
That worked. How can I remove apps I do not plan to use, such as JellyFin, because I am running them on another server?
Chris wrote:
I can help you choose the safe option. Do you want to stop Jellyfin from running while keeping its data and settings, or are you also trying to reclaim the disk space it uses? Those can involve different steps, so please don't delete its files or use a reset/cleanup option yet. Since you're running SparkBox in a Proxmox VM, I'll tailor the steps to that setup.
mtechnic wrote:
I'm trying to reclaim disk space for services I do not need like Jellyfin and SABnbzd
Chris wrote:
For reclaiming space used by unused app images, SparkBox 1.6.842 adds a Tom AI cleanup offer when Docker reports at least 500 MB reclaimable; update to 1.6.842 or newer, then ask Tom AI about freeing disk space. It will explain the amount and ask you to confirm before cleaning up. This removes older app images kept for Roll Back and images of switched-off apps, not the apps' data or settings, so it won't remove Jellyfin or SABnzbd's stored data. If your goal is to remove the apps themselves rather than just reclaim image space, tell me and I can guide that separately.