Hi everyone, in proxmox I have three drives configured in nfs to be raid z which I then assigned majority space to about 24tb to the vm machine running ubuntu server that I have sparkbox on. However in sparkbox it only shows having a disk of 97.9gb. SABnzbd seems to be showing a similiar amount of space available. Is there a way to see or adjust how much of my raid config sparkbox and the containers have access too? Side note: I have several external hard drives with media I would like to get into jellyfin on the media stack. Is there an easy way to do this with one of the containers on the media stack Radarr or something or through sparkbox itself?
43 replies
tomspark wrote:
Using the RAID as the boot disk isn't the problem in itself — SparkBox just uses the space on whatever drive the OS is installed on, so a 24TB boot drive is totally fine. What matters is how much of that 24TB the VM actually sees. Run this and paste it: df -h / If it shows roughly 24TB, the space is there and we'll look at why SparkBox isn't using it. If it shows a lot less (like a default 30–60GB), then the VM was handed a smaller virtual disk than the full RAID — the fix is to grow the VM's disk and then expand the filesystem inside Ubuntu, which I'll walk you through. Which one are you seeing?
tomspark wrote:
Exactly what I needed — and good news, it's a 2-command fix, no Proxmox changes needed. Your disk IS the full 23.4TB (lsblk shows sda = 23.4T); the catch is Ubuntu's installer only gave the root volume 100GB of it and left the other ~23TB sitting unused inside the volume group. So we just grow the volume to fill the disk, then grow the filesystem onto it. Run these two: sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv sudo resize2fs /dev/ubuntu-vg/ubuntu-lv Then check it took: df -h / You should see / jump from 98G to ~23T. It's a live, non-destructive operation — nothing gets wiped and you don't even need to reboot. That gives SparkBox the full space for your media. Once that's done, we can sort getting your external drives into Jellyfin.
tomspark wrote:
That's the one — 24TB live, nicely done! 🎉 You've got the right idea on the drives. The clean version, two steps: 1. Plug the external drive into the server, then in the Proxmox web UI: pick your VM - Hardware - Add - USB Device - select your drive. That passes the physical drive straight into the VM. 2. Back in the VM, run: lsblk -f You'll see the new drive show up (something like sdb1) along with its filesystem type. Paste that line and I'll give you the exact mount + copy commands — they differ slightly depending on whether the drive is NTFS, exFAT, or ext4 (Windows drives are usually NTFS), so I don't want to guess. Once it's mounted it's basically one rsync command per folder (movies into your media's movies folder, tv into tv, etc.) and Jellyfin picks them up on its next scan. Send me that lsblk -f and we'll knock it out.
tomspark wrote:
Perfect — those are all TV shows, and your media folder is /opt/sparkbox/data/media, so everything goes into the TV folder. Here's the exact copy command — paste it as one line: sudo rsync -av --info=progress2 "/mnt/usb/Attack on Titan" "/mnt/usb/Futurama" "/mnt/usb/Rick and Morty" "/mnt/usb/Slow Horses" /opt/sparkbox/data/media/TV/ It'll show progress as it copies — could take a while for that much video, totally normal. When it finishes, run this so the apps can read the files: sudo chown -R 1000:1000 /opt/sparkbox/data/media/TV Then in Jellyfin: Dashboard → Libraries → Scan, and your shows pop up. (Ignore the $RECYCLE.BIN and System Volume Information folders — those are just Windows junk.)
tomspark wrote:
You've nailed the diagnosis — that 97.9GB is just your Ubuntu VM's system disk, where SparkBox itself is installed. Your 24TB RAID-Z is a separate volume, and SparkBox defaults to storing media on the small system disk, which is why SAB looks tiny. To switch it over: (1) confirm the 24TB is actually mounted inside the Ubuntu VM — run df -h and you should see it listed at a folder like /mnt/storage (if it's not there, it needs mounting in Ubuntu first). (2) Then edit /opt/sparkbox/.env, set MEDIAROOT to that path (e.g. MEDIAROOT=/mnt/storage), and run sudo sparkbox up — use up, not restart, as restart won't re-mount. All the media apps then use the 24TB. For your external drives: simplest is to copy that media into the Movies and TV folders under your new MEDIAROOT — Jellyfin scans it in automatically (Radarr/Sonarr are more for fetching new releases than importing an existing library). Shout if df -h doesn't show the big drive and we'll sort the mount.
Technofly17 wrote:
Hm it's not showing up I am noticing I set that 24tb raid as the boot disk for the ubuntu server vm I'm running sparkbox on which I assume may be causing the issue?
Technofly17 wrote:
It threw the error df: invalid option -- '/' Side note my power went out not long ago and my server does not have a ups as of yet and after getting everything back up and running sparkbox up when I try to load the dashboard I get a problem loading page the connection has timed out...
tomspark wrote:
Two things — and let's sort the dashboard first since that's the bigger one. After an unclean power-off, the dashboard sometimes doesn't come back cleanly. Run these and paste the output: sudo docker ps -a | grep sb-dashboard sudo sparkbox doctor The first shows whether the dashboard container is actually running (vs stuck/crashed/restarting); doctor checks the whole stack. If the dashboard's down or looping, that's our fix target. (And the df error was just a typo on the slash — run it as plain df -h, no slash, and look for the big 24TB filesystem.) Also, genuinely worth grabbing a cheap UPS when you can — unclean power-offs are the 1 thing that leaves containers in a bad state. Paste those two outputs and I'll get you back in.
Technofly17 wrote:
Okay the docker command gave 40c1b38f221e sparkbox-sparkbox-dashboard "/app/entrypoint.sh ..." 40 minutes ago Up 20 minutes (healthy) 0.0.0.0:8443-8443/tcp Then underneath it has sb-dashboard in red sparkbox doctor returns everything [OK] the df -h UPS is definitely 1 on the to buy list!
tomspark wrote:
That's the issue — the unclean restart left you with TWO dashboard containers (the healthy one, plus that dead red sb-dashboard), and they're tripping over each other on port 8443. Let's clear both and bring up one clean one: sudo docker rm -f sb-dashboard sparkbox-sparkbox-dashboard sudo sparkbox up Give it ~30 seconds, then load http://<your-server-IP:8443 — it should come right up. (doctor passing is a good sign the rest of the stack is healthy.) On the disk: I can see your df output but it's too small for me to read the root line — what does the line for / show under Size? That'll tell us whether the full 24TB is actually there.
Technofly17 wrote:
Okay so the rm command returns the error Error response from daemon: No such container: sparkbox-sparkbox-dashboard For thew disk the size is 98G.
tomspark wrote:
No problem — the "no such container" just means that duplicate was already gone, so the cleanup did its job. Did the dashboard come back after sudo sparkbox up? Try loading http://<your-IP:8443 now — if it still won't load, paste sudo docker ps | grep dashboard and I'll see what's there. And that 98G is the smoking gun for your RAID question: your Ubuntu VM only sees a 98GB disk, not the full 24TB. So the space is there on the host, but the VM was only handed ~98GB of it. The fix is to grow the VM's virtual disk and then expand the filesystem inside Ubuntu. What are you running the VM in — Proxmox, ESXi, VirtualBox, something else? That tells me the exact steps.
Technofly17 wrote:
Sadly loading the dashboard still times out. I'm on proxmox with an ubuntu server VM. (I did decide for some reason if I'm going into self hosting I'm going all in and went proxmox haha)
tomspark wrote:
Let's pin down whether it's the dashboard itself or the network in between. On the VM, run these two and paste: sudo docker ps | grep dashboard curl -k -m 5 https://localhost:8443 If that curl gets ANY response (even an error page), the dashboard IS up and it's a reaching-it-from-your-browser thing — almost always the IP. In a Proxmox VM you want the VM's OWN IP at :8443, not the Proxmox host's IP. What address are you typing in? If the curl just times out too, the container isn't serving and we dig there. (Proxmox — nice, going all in! Once the dashboard's back I'll give you the exact Proxmox steps to grow that VM disk out to the full 24TB.)
Technofly17 wrote:
Alright for grep dashboard for the curl Looks like it isnt serving for some reason.
tomspark wrote:
Those screenshots are really helpful — two things I can see: 1. Your dashboard container IS running and healthy, bound to port 8443 — so it's not actually down. (Small note: it came up named 'sparkbox-sparkbox-dashboard' instead of the usual 'sb-dashboard' — a known glitch from an unclean shutdown, harmless but I've flagged it on our end.) 2. The curl couldn't reach 8443, so this is a 'reaching the port' problem, not a 'dashboard is down' one. Run this one exactly, from inside the VM (same terminal as the docker ps): curl -I http://localhost:8443 If that returns some header lines, the dashboard is fine and the issue is how you're reaching it from your browser — either you're hitting the wrong IP (use the VM's own IP, not the Proxmox host's), or the VM's firewall is blocking 8443 to other machines, and we'll open that. If that ALSO fails, the 'healthy' flag is misleading and we'll rebuild it clean. Tell me which way it goes. (I haven't forgotten the 24TB disk question — let's get you logged in first, then sort the storage.)
Technofly17 wrote:
Same failed to connect (running it in the vm).
tomspark wrote:
Ok, that's actually decisive: the dashboard genuinely isn't serving on 8443, even though Docker marks it 'healthy.' And the container name is the giveaway — SparkBox always names it 'sb-dashboard', but yours is 'sparkbox-sparkbox-dashboard', which is how Docker Compose / Portainer names a stack it deployed itself. Question: did you ever deploy or redeploy SparkBox (or just the dashboard) as a Stack inside Portainer? If so that's almost certainly it — Portainer's copy is fighting SparkBox's own, and neither serves cleanly. Let's reset it to the SparkBox-managed one: sudo docker rm -f sb-dashboard sparkbox-sparkbox-dashboard sudo sparkbox up sudo docker ps | grep dashboard That last line should now show ONLY sb-dashboard. If 'sparkbox-sparkbox-dashboard' comes BACK, then Portainer (or a leftover compose stack) is recreating it — delete that stack in Portainer first, then re-run the three lines. Once you see just sb-dashboard, try the browser again.
Technofly17 wrote:
Hm when I ran the remove command it threw this error. I then did sparkbox up and after everything was back up ran the docker ps and it showed up again. I have yet to mess around in portainer so I dont think I ever deployed or redeployed it.
tomspark wrote:
Actually — I need to correct myself, my mistake. I misread your first screenshot: 'sparkbox-sparkbox-dashboard' is just the IMAGE name (that's the middle column in docker ps, and it's the normal name for the built dashboard image). Your actual container is named 'sb-dashboard', which is exactly right — and your rm output confirms it (sb-dashboard removed fine, the other 'No such container'). So there's no duplicate and Portainer isn't involved. Sorry for the runaround there. So it's simpler than I made it: sb-dashboard is running fine on 8443, just not reachable where you're curling. Two steps: 1. Your latest ps still says 'health: starting' — give it a full minute, then confirm it shows '(healthy)': sudo docker ps | grep sb-dashboard 2. Once healthy, run this exactly (localhost, inside the VM): curl -I http://127.0.0.1:8443 If that returns header lines, the dashboard is fine and your browser just can't reach it — almost always the VM's firewall. Run 'sudo ufw status'; if it's active, 'sudo ufw allow 8443' opens the port, then browse to the VM's IP:8443. If 127.0.0.1:8443 STILL fails once it's healthy, grab 'sudo docker logs sb-dashboard --tail 30' and I'll see what's wrong inside.
Technofly17 wrote:
That curl showed mountains of stuff is that header lines? Looks like the port is open ran the ufw allow still times out Here is the dashboard logs.
tomspark wrote:
That actually narrows it right down. The 'mountains of stuff' from the curl is the dashboard's own web page — so the dashboard IS running and serving on 8443 inside the VM, and ufw is open. Both of those are fine. The only thing left is your browser reaching the VM. The usual Proxmox cause: you're browsing to the wrong IP — often the Proxmox HOST's IP instead of the VM's own. Get the VM's actual IP by running this inside the VM: hostname -I It'll show something like 192.168.x.x. Open http://<that-exact-ip:8443 in your browser, from a computer on the same network as the VM. One more check: is the machine you're browsing from on the same subnet as the VM? If the VM is on a different network/VLAN in Proxmox, it'd time out even with the dashboard and firewall both fine. Tell me the VM's IP and what address you're typing in the browser.
Technofly17 wrote:
Woah that worked! Interesting so the Ip that showed up ended in .54 before the power outage the ip for the dashboard ended in .64 as I've confirmed with my notes sheet. Also when sparkbox goes up and lists all the ip's it was still showing 64. I'm glad it works now but I'm very interested as to what caused the change?
tomspark wrote:
Love it — dashboard's back! Here's the mystery solved: after the power outage your router handed the VM a new IP (.54), but you'd been browsing the old one (.64). The IP 'changed' because your router assigns it via DHCP, and the lease shifted when everything rebooted. Two follow-ups: 1. You're right that 'sparkbox up' still listed .64 — that's SparkBox showing a cached IP from install time instead of the live one. I'll flag it to get fixed. For now, hostname -I is always the source of truth. 2. To stop this recurring: set a DHCP reservation for the VM in your router (pin its MAC to a fixed IP), and the dashboard address will never move again. Now that you're in — want to tackle the 24TB disk showing as 98GB next? That one's a Proxmox VM-disk resize (grow the virtual disk, then expand the filesystem). Just say the word and I'll walk you through it.
Technofly17 wrote:
Please do walk me through it I am here and ready! Good to know on the ip I will pin it on my router! A UPS is also on order so hopefully this is a one time occurance haha. Thanks so much for helping so far its been fantastic.
tomspark wrote:
Great — and smart move on the UPS. Before I hand you commands, one quick look so I give you the EXACT right steps, because the fix is different depending on how the 24TB is attached (a big disk that just needs its partition grown, vs a separate disk we need to mount). In the VM, run these two and paste the output: lsblk df -h / lsblk shows all your disks and their real sizes; df shows what the system is actually using right now. From those I'll know in one glance whether we grow an existing partition or mount the big drive, and I'll give you the precise commands — won't be more than a couple of steps either way.
Technofly17 wrote:
Okie Dokie And then is this what you were looking for?
Technofly17 wrote:
Sweet sweet. Looks like everything is going good I think? Still waiting on df -h I suspect having it go through that many TB might be what's causing it to take longer than usual. I just noticed sparkbox seems to be showing the change in real time the /11.4 is slowly climbing!
tomspark wrote:
That's it working perfectly — your screenshot shows the volume grew from 100GB to 23.44TB and the filesystem resize is running. On a 23TB volume, resize2fs legitimately takes a few minutes because it has to write thousands of new block descriptors (that's the 'olddescblocks 13 → new 3000' line). The number climbing in real time IS the resize doing its thing — totally normal, just let it finish. When df -h finally returns, you'll see / at ~23T. Nothing to babysit; it can't hurt anything mid-resize. Once it lands, give me a shout and we'll get your external drives showing up in Jellyfin.
Technofly17 wrote:
Woohoo it just landed 24tb showing up nice! For those external drives I was hoping to move the media onto the raid array whats the best way to go about it. I tried digging around online this morning about it and it all seemed a bit convoluded on the best way to do it or really how. From what I understood the best way to do it was plug the drive into the server and pass it through to the VM then copy the files over with a couple commands? Not sure which commands though I got lost at that point.
Technofly17 wrote:
Mounted it and when I went back tot he console it seems like it might be stuck on something... it's got the dash bar blinking as it seems to be pondering.
tomspark wrote:
Good news — you're not actually stuck. That line ('[sdb] Asking for cache data failed') is just a harmless kernel notice that USB drives throw when they don't answer a cache query — totally normal, and it actually tells us your drive got detected fine (it's now 'sdb'). The blinking bit is just your cursor sitting at the prompt. Just press Enter to get a clean line, then run: lsblk -f The new drive will show up as sdb (with a partition like sdb1 and its filesystem type next to it). Paste that and I'll hand you the exact mount + copy commands.
Technofly17 wrote:
Oh cool cool. Looks like this puppy is exfat.
tomspark wrote:
Perfect — it's /dev/sdb1, exFAT, labeled 'Fuji'. You're on Ubuntu 26.04 so exFAT support is built in. Mount it: sudo mkdir -p /mnt/usb sudo mount /dev/sdb1 /mnt/usb (If that says 'unknown filesystem type exfat', run: sudo apt install -y exfatprogs then re-run the mount.) Then see what's on the drive and where your media lives: ls /mnt/usb grep MEDIAROOT /opt/sparkbox/.env Now the copy — one rsync per media type, matching the folder names from that ls into your media folders. Example, if the drive has a 'Movies' folder and your MEDIAROOT is /data: sudo rsync -av --info=progress2 /mnt/usb/Movies/ /data/movies/ sudo rsync -av --info=progress2 /mnt/usb/TV/ /data/tv/ (rsync shows live progress and is safe to re-run if it gets interrupted.) When it's done, fix ownership so the apps can read it: sudo chown -R 1000:1000 /data Then in Jellyfin go to Dashboard - Libraries - Scan, and your media shows up. If you'd like me to write the exact lines for your actual folder names, just paste the ls + grep output and I'll tailor them for you.
Technofly17 wrote:
I seem to have gotten stuck almost immediately haha Didnt throw any errors when I ran sudo mkdir -p /mnt/usb
tomspark wrote:
Ah, easy one — you didn't break anything, it's just a missing space. In that mount line the drive and the folder need a space between them, otherwise it reads them as one thing and goes hunting in the wrong place (that's the '/etc/fstab' message you're seeing). Run it exactly like this, with the space between sdb1 and /mnt/usb: sudo mount /dev/sdb1 /mnt/usb If it comes back with no message at all, that means it worked. Then you can peek at what's on the drive with: ls /mnt/usb
Technofly17 wrote:
Ah there we go. The not being able to copy and paste into this console finally got me haha.
tomspark wrote:
Haha yeah, those text-only consoles will get you — glad it mounted! Now let's see what's actually on the drive so I can hand you the exact copy commands. Run these two and paste both back: ls /mnt/usb grep MEDIAROOT /opt/sparkbox/.env The first shows the folders on your USB drive, the second shows where SparkBox keeps your media. Once I see them I'll write the precise copy lines for your actual folder names — no guessing.
Technofly17 wrote:
Alright first one is. And second is
Technofly17 wrote:
Oh wow look at it go awesome thank you! Now once this is all done and I remove the drive and say put some other media on it down the line and plug it back into the server I would have to remount it and everything to do this again or does it remember the drive as long as it is the same one?
tomspark wrote:
Glad it's flying! Short version: the drive remembers its own files, but the server doesn't auto-remember the drive. So each time you unplug it and plug it back in down the line, you'd just run the mount step again, then copy the new stuff — same two commands as today. One small heads-up: the drive's name (sdb1 this time) can change depending on what else is plugged in, so each time run lsblk -f first to spot it, then: sudo mount /dev/sdX1 /mnt/usb (swap sdX1 for whatever lsblk shows). After that it's the same rsync into your TV or Movies folder. No permanent setup needed for an occasional copy like this.
Technofly17 wrote:
Awesome I shall be saving this as reference for the future! Thanks so much for helping me out this past week or so. I had spent about two weeks grinding away to get a home server up in running with at least a media stack with very little success until I came across Sparkbox. This kind of software is absolutely perfect for someone like me wants to self host stuff but doesnt exactly have enough coding background to do it in a reasonable amount of time (without my head exploding). I dont think I would have a server nearly this functional without sparkbox and I'm very excited to back it and see where it leads in the future. Keep up the good work!
tomspark wrote:
That genuinely made my day to read — it's exactly why SparkBox exists. You did the hard part by sticking with it through the rough setup. Enjoy the server, and you know where to find us if anything else ever comes up. 🎉