[Template only, I am not the container author/maintainer]

 

Template: https://github.com/m-klecka/unraid-templates/blob/main/spoolman/spoolman.xml

Source container: https://github.com/Donkie/Spoolman

 

Spoolman is a docker application with Klipper support for tracking filament spool usage.

 

I'll try to provide support for the template here, but any issues with the container should be posted to the creator's github repo

 

The default data path inside container has problem with unraid appdata permissions. After installing open unraid console and run "sudo chown -R 1000:1000 /mnt/user/appdata/spoolman" (or your different specified appdata path) to fix the issue.

Edited December 6, 20232 yr by mklecka
Edited permission error fix

Hi!

I'm sorry to say, but I'm having troubles with your Template.

 

After you changed the internal path to data the next error is that the logging level is not set.

I set it to INFO. After that the template complains that the DB type is not set. I just want to use the built-in sqlite DB. No external DB required for me. With the nightly backups that should be more than enough for my 10-20 spools.

 

Am i missing something or doing something wrong?

 

I would really like to use the application and the companion plugin for octoprint.

Edited October 20, 20232 yr by oldrobot

7 hours ago, oldrobot said:

Hi!

I'm sorry to say, but I'm having troubles with your Template.

 

After you changed the internal path to data the next error is that the logging level is not set.

I set it to INFO. After that the template complains that the DB type is not set. I just want to use the built-in sqlite DB. No external DB required for me. With the nightly backups that should be more than enough for my 10-20 spools.

 

Am i missing something or doing something wrong?

 

I would really like to use the application and the companion plugin for octoprint.

Hi, did you remove every variable you are not using? If you just want to use sqlite then basically remove everything except the path and port variables.

Wow, you are absolutely right! That's a behaviour of Templates I did not know until now (that I proactively had to remove variables out of the template). Thank you for the explanation. Actually I should have taken the "remove if unused" literally and not interpret it as "just leave it empty". Thank you!!!

New update, new problem. Maybe it's again my fault. Anyway: With the last update I lost all data (all vendors, filaments and spools). Researching the issue I see that the folder in /usr/appdata/spoolman is empty. Therefore I understand that updating the docker image and container erased all data because it seems not to be mapped to the correct folder where the config and db seem to reside. If I understand correctly the author of spoolman gives this bit of documentation for docker deployments:

 

version: '3.8'
services:
  spoolman:
    image: ghcr.io/donkie/spoolman:latest
    restart: unless-stopped
    volumes:
      # Mount the host machine's ./data directory into the container's /home/app/.local/share/spoolman directory
      - type: bind
        source: ./data # This is where the data will be stored locally. Could also be set to for example `source: /home/pi/printer_data/spoolman`.
        target: /home/app/.local/share/spoolman # Do NOT change this line
    ports:
      # Map the host machine's port 7912 to the container's port 8000
      - "7912:8000"
    environment:
      - TZ=Europe/Stockholm # Optional, defaults to UTC

 

Where the source bind would be ./data (translated to unraid this is /usr/appdata/spoolman) and the target (inside the container) would be /home/app/.local/share/spoolman.

But what we do since it originally wouldn't deploy with this settings (before you first updated your template) is the opposite. We map /usr/appdata/spoolman to /data (inside the container). This folder is not supposed to contain anything and even though it is mounted by docker nothing is ever saved there. How should we proceed in the future?

Edited October 25, 20232 yr by oldrobot

On 10/25/2023 at 11:50 AM, oldrobot said:

New update, new problem. Maybe it's again my fault. Anyway: With the last update I lost all data (all vendors, filaments and spools). Researching the issue I see that the folder in /usr/appdata/spoolman is empty. Therefore I understand that updating the docker image and container erased all data because it seems not to be mapped to the correct folder where the config and db seem to reside. If I understand correctly the author of spoolman gives this bit of documentation for docker deployments:

 

version: '3.8'
services:
  spoolman:
    image: ghcr.io/donkie/spoolman:latest
    restart: unless-stopped
    volumes:
      # Mount the host machine's ./data directory into the container's /home/app/.local/share/spoolman directory
      - type: bind
        source: ./data # This is where the data will be stored locally. Could also be set to for example `source: /home/pi/printer_data/spoolman`.
        target: /home/app/.local/share/spoolman # Do NOT change this line
    ports:
      # Map the host machine's port 7912 to the container's port 8000
      - "7912:8000"
    environment:
      - TZ=Europe/Stockholm # Optional, defaults to UTC

 

Where the source bind would be ./data (translated to unraid this is /usr/appdata/spoolman) and the target (inside the container) would be /home/app/.local/share/spoolman.

But what we do since it originally wouldn't deploy with this settings (before you first updated your template) is the opposite. We map /usr/appdata/spoolman to /data (inside the container). This folder is not supposed to contain anything and even though it is mounted by docker nothing is ever saved there. How should we proceed in the future?

Hi, i trying to resolve the permission issues on Spoolman github, but nothing so far. The workaround is manually changing permissions for the appdata folder created (i dont know why its created with wrong permissions). You can use the original path to the container data folder "/home/app/.local/share/spoolman" and manually change appdata folder permissions to this

or run the new permissions tool from "Tools" tab in the unraid menu.

Hi! I digged a little bit and your template is not the problem. It seems the container itself is the "problem".

 

I tried to redeploy the application mapping /mnt/user/appdata/spoolman to "/home/app/.local/share/" and voila. It deploys even with default permissions. If I go to "/mnt/user/appdata/spoolman" I find that a subfolder named "spoolman" has been created. That means that we map a Volume to a folder that does not exist before the application is deployed. Therefore the system won't let us create the folder on the host.

 

I think what happens is that the docker container will try to create the spoolman folder on "first install" (when we deploy the container). So this happens on first install, on updates and so on. Therefore I think the "culprit" is to be found in the dockerfile at:

 

# Add local user so we don't run as root
RUN adduser -D app \
    && mkdir -p /home/app/.local/share/spoolman \
    && chown -R app:app /home/app/.local/share/spoolman

 

This tries to create the directory and set permissions for a directory mapped to host which might be the reason of failure. I'm just guessing here, because this happens in the "Nimbus" between host and docker instance. I could not say if this is really the problem. But again, if mapped to the parent directory "/home/app/.local/share/" the directory spoolman is created and everything runs as it should.

 

Maybe I misunderstand, but it would seem to be the only logical explaination to the behaviour we are seeing.

 

I hope this can help you down the path of finding what is going wrong.

On 10/28/2023 at 9:52 PM, oldrobot said:

Hi! I digged a little bit and your template is not the problem. It seems the container itself is the "problem".

 

I tried to redeploy the application mapping /mnt/user/appdata/spoolman to "/home/app/.local/share/" and voila. It deploys even with default permissions. If I go to "/mnt/user/appdata/spoolman" I find that a subfolder named "spoolman" has been created. That means that we map a Volume to a folder that does not exist before the application is deployed. Therefore the system won't let us create the folder on the host.

 

I think what happens is that the docker container will try to create the spoolman folder on "first install" (when we deploy the container). So this happens on first install, on updates and so on. Therefore I think the "culprit" is to be found in the dockerfile at:

 

# Add local user so we don't run as root
RUN adduser -D app \
    && mkdir -p /home/app/.local/share/spoolman \
    && chown -R app:app /home/app/.local/share/spoolman

 

This tries to create the directory and set permissions for a directory mapped to host which might be the reason of failure. I'm just guessing here, because this happens in the "Nimbus" between host and docker instance. I could not say if this is really the problem. But again, if mapped to the parent directory "/home/app/.local/share/" the directory spoolman is created and everything runs as it should.

 

Maybe I misunderstand, but it would seem to be the only logical explaination to the behaviour we are seeing.

 

I hope this can help you down the path of finding what is going wrong.

Hey!

I updated the docker and lost my database. I read what you found out, but I can't really see if there is a solution or not. Is there a way to restore my old database? If not, how should I proceed to not lose it again when updating?

1 hour ago, Lecso said:

Hey!

I updated the docker and lost my database. I read what you found out, but I can't really see if there is a solution or not. Is there a way to restore my old database? If not, how should I proceed to not lose it again when updating?

Hi, mount appdata to the original path "/home/app/.local/share/spoolman", start the container and if it shows permission error in the log run New Permissions from the "Tools" menu in unraid. That should fix it and database should be in the right place in appdata

Any chance you could create a template for the Bambu lap integration plugin?
bambulab-ams-spoolman-filamentstatus
https://github.com/Rdiger-36/bambulab-ams-spoolman-filamentstatus

Edited November 23, 2025Nov 23 by egoon

I see that there were some issues with permissions and losing data on upgrade, but that these were from 2023, and it's now early 2026.

Have these all been fixed, or do I still need to worry about permissions?

Do I need to worry about loosing data if/when there's an update?