Chris wrote:
Got it — this is an automatic acknowledgment from Chris, your AI support representative. 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:
You're not slow, this one is genuinely confusing, and I'm sorry Tom AI kept sending you round the same loop. On a UGREEN NAS, SparkBox installs itself and every app's settings to /opt/sparkbox, which is on the NAS's small built-in system drive, not on your storage drives. Your media shared folder, your downloads and the app images all live on the storage drives. An update needs about 2 GB free on the system drive, so that is the one that is full, and that is why you can't find anything to delete: none of your own files are on it. It's also why clearing app images (what Tom AI kept suggesting) changes nothing there. What usually fills it is SparkBox's own local backups. Each one is a copy of every app's settings and databases, and they pile up in /opt/sparkbox/backups. One check, over SSH on the NAS: sudo du -xh -d2 /opt | sort -h | tail -n 15 The last lines are the biggest folders on that drive. If /opt/sparkbox/backups is near the bottom of the list (the very last lines are just the totals for /opt and /opt/sparkbox), run ls -lh /opt/sparkbox/backups and delete the older backup files with sudo rm followed by each file's full path, keeping the newest one. Please don't delete anything under /opt/sparkbox/modules or /opt/sparkbox/state: those are your apps' own settings. Then press Update again. If that drive is completely full, that alone can stop the apps working too, since they write their settings there, so this may fix that as well. If backups isn't the big one, paste those last lines here and I'll tell you what each is. Two small things: if your update message ends with "the disk Docker keeps app images on" instead of /opt/sparkbox, it's your storage drives that are full, so tell me that instead. And I've added this to what the assistant knows, and the next SparkBox update makes that message list the biggest folders itself, so the next person doesn't have to hunt.
QuintoneArmado wrote:
4.0K /opt/sparkbox/templates 8.0K /opt/sparkbox/scripts 12K /opt/containerd 44K /opt/sparkbox/data 68K /opt/sparkbox.rollback-1788323335/dashboard 68K /opt/sparkbox.rollback-1789684433/dashboard 72K /opt/sparkbox/dashboard 284K /opt/sparkbox.rollback-1788323335/modules 296K /opt/sparkbox.rollback-1789684433/modules 376K /opt/sparkbox.rollback-1788323335 388K /opt/sparkbox.rollback-1789684433 172M /opt/sparkbox/modules 189M /opt/sparkbox/state 360M /opt/sparkbox 361M /opt
Chris wrote:
I'm sorry—I shouldn't have told you to delete older backups; we hadn't established that they were filling the disk. The update-space fix is in SparkBox 1.6.870: it identifies the largest folders on the actual install drive, instead of pointing you at folders that may not be the cause. If your box can run the update, use sudo sparkbox update and then sudo sparkbox up to reach 1.6.870 or later; if it still refuses for space, please share the exact refusal message (with any private paths redacted) and don't delete anything yet. I've corrected what I know so this unsupported advice isn't repeated for someone else.