oldrobot

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.

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?

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!!!

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.

Same here in Austria 😞