[GH-ISSUE #1215] [Bug]: Virtual Printer Permission Denied [Error 13] #880

Closed
opened 2026-05-06 12:33:39 +02:00 by BreizhHardware · 3 comments

Originally created by @Carter3DP on GitHub (May 5, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1215

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

I am unable to use virtual printer functions due to getting Permission Denied errors on the virtual_printer folder in bambuddy_data on a docker installation. More info in issue #1211

Expected Behavior

virtual_printers should be able to be read from and written to.

Steps to Reproduce

  1. Setup docker installation using the pre-built image method on linux: https://wiki.bambuddy.cool/getting-started/docker/
  2. Create a virtual printer
  3. Check application logs, you may see [-] Failed to sync virtual printers: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads'

Printer Model

Not printer-related

Bambuddy Version

v0.2.4b2

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

No response

Screenshots

Image

Additional Context

No response

Checklist

  • I have searched existing issues to ensure this bug hasn't already been reported
  • I am using the latest version of Bambuddy
  • My printer is set to LAN Only mode
  • My printer has Developer Mode enabled
Originally created by @Carter3DP on GitHub (May 5, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1215 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description I am unable to use virtual printer functions due to getting Permission Denied errors on the virtual_printer folder in bambuddy_data on a docker installation. More info in issue #1211 ### Expected Behavior virtual_printers should be able to be read from and written to. ### Steps to Reproduce 1. Setup docker installation using the pre-built image method on linux: https://wiki.bambuddy.cool/getting-started/docker/ 2. Create a virtual printer 3. Check application logs, you may see `[-] Failed to sync virtual printers: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads'` ### Printer Model Not printer-related ### Bambuddy Version v0.2.4b2 ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package _No response_ ### Screenshots <img width="990" height="383" alt="Image" src="https://github.com/user-attachments/assets/5110c924-c727-434f-816b-741c25629c8d" /> ### Additional Context _No response_ ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled
BreizhHardware 2026-05-06 12:33:39 +02:00
Author
Owner

@maziggy commented on GitHub (May 5, 2026):

That's the actual root cause. The "Cannot create directory /app/data/virtual_printer/uploads" path is a bind mount in your
compose:

- ./virtual_printer:/app/data/virtual_printer

so /app/data/virtual_printer is the host's ./virtual_printer directory, and the named-volume chmod 777 doesn't help — what
matters is the on-disk permissions of that host path.

When docker compose first sees a missing bind-mount source it creates the directory as root (the daemon runs as root), so the host dir starts root-owned and uid 1000 inside the container can't mkdir uploads under it. chown -R 1000:1000 should fix it, but since you've tried that twice and the error persists, I want to rule out three things:

# 1. Verify the path you chown'd is the one docker is actually
#    bind-mounting. Run from the dir that contains your
#    docker-compose.yml:
pwd
ls -ld virtual_printer
ls -ld virtual_printer/

# 2. Check what the container itself sees:
sudo docker compose exec bambuddy ls -ld /app/data/virtual_printer
sudo docker compose exec bambuddy id

# 3. Check whether AppArmor is involved (Ubuntu's default Docker
#    profile sometimes denies bind-mount writes even with the
#    right POSIX owner):
sudo dmesg | grep -i 'apparmor.*denied' | tail -20

(1) confirms which directory is actually being mounted, (2) shows the ownership the container sees and the uid it's running as, and (3) tells us whether AppArmor is silently blocking the write.

If (1) and (2) agree on 1000:1000 and (3) is empty, the fix is to also chown the contents — chown -R is not always enough if a
sub-file was created by the container as root before you ever chown'd:

sudo chown -R 1000:1000 virtual_printer

If (3) shows AppArmor denials, the cleanest workaround is the named-volume path: comment out the ./virtual_printer bind mount line in your compose, run docker compose up -d, and the VP directories live inside the named volume where chmod 777 actually applies. You only need the bind mount if you're sharing the cert with a separate native install — which is the only reason it's in the template. Most Docker-only users can safely drop it.

Separately on our end: the shipped docker-compose.yml has this bind mount uncommented by default, which trips every Docker user who isn't sharing certs (you're the second report). That'll be commented out and gated behind a clear comment in a follow-up.


Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.


If you find Bambuddy useful, please consider giving it a on GitHub — it helps others discover the project!

<!-- gh-comment-id:4380709089 --> @maziggy commented on GitHub (May 5, 2026): That's the actual root cause. The "Cannot create directory /app/data/virtual_printer/uploads" path is a bind mount in your compose: - ./virtual_printer:/app/data/virtual_printer so /app/data/virtual_printer is the host's ./virtual_printer directory, and the named-volume chmod 777 doesn't help — what matters is the on-disk permissions of that host path. When docker compose first sees a missing bind-mount source it creates the directory as root (the daemon runs as root), so the host dir starts root-owned and uid 1000 inside the container can't mkdir uploads under it. chown -R 1000:1000 should fix it, but since you've tried that twice and the error persists, I want to rule out three things: # 1. Verify the path you chown'd is the one docker is actually # bind-mounting. Run from the dir that contains your # docker-compose.yml: pwd ls -ld virtual_printer ls -ld virtual_printer/ # 2. Check what the container itself sees: sudo docker compose exec bambuddy ls -ld /app/data/virtual_printer sudo docker compose exec bambuddy id # 3. Check whether AppArmor is involved (Ubuntu's default Docker # profile sometimes denies bind-mount writes even with the # right POSIX owner): sudo dmesg | grep -i 'apparmor.*denied' | tail -20 (1) confirms which directory is actually being mounted, (2) shows the ownership the container sees and the uid it's running as, and (3) tells us whether AppArmor is silently blocking the write. If (1) and (2) agree on 1000:1000 and (3) is empty, the fix is to also chown the contents — chown -R is not always enough if a sub-file was created by the container as root before you ever chown'd: sudo chown -R 1000:1000 virtual_printer If (3) shows AppArmor denials, the cleanest workaround is the named-volume path: comment out the ./virtual_printer bind mount line in your compose, run docker compose up -d, and the VP directories live inside the named volume where chmod 777 actually applies. You only need the bind mount if you're sharing the cert with a separate native install — which is the only reason it's in the template. Most Docker-only users can safely drop it. Separately on our end: the shipped docker-compose.yml has this bind mount uncommented by default, which trips every Docker user who isn't sharing certs (you're the second report). That'll be commented out and gated behind a clear comment in a follow-up. ------------------- Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!
Author
Owner

@Carter3DP commented on GitHub (May 5, 2026):

It was user error. After checking the ownership of /virtual_printer/ in the same folder as docker-compose.yml, it was root root. I ran sudo chown -R 1000:1000 virtual_printer in that folder and virtual printers now work.
Thank you so much.

Image
<!-- gh-comment-id:4380785502 --> @Carter3DP commented on GitHub (May 5, 2026): It was user error. After checking the ownership of /virtual_printer/ in the same folder as docker-compose.yml, it was root root. I ran sudo chown -R 1000:1000 virtual_printer in that folder and virtual printers now work. Thank you so much. <img width="1389" height="595" alt="Image" src="https://github.com/user-attachments/assets/ab1c823d-e06e-46e3-b3af-db54f3b7b145" />
Author
Owner

@maziggy commented on GitHub (May 5, 2026):

Glad it works for you.


If you find Bambuddy useful, please consider giving it a on GitHub — it helps others discover the project!

<!-- gh-comment-id:4380802608 --> @maziggy commented on GitHub (May 5, 2026): Glad it works for you. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/bambuddy#880
No description provided.