[GH-ISSUE #1211] [Bug]: Backup Not Restored Properly

BreizhHardware commented

2026-05-07 00:14:38 +02:00

Owner

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

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

I was having issues with the virtual printer (Error 13: Permission Denied) so I created a backup and then:

docker compose stop
docker compose rm -v
docker volume remove bambuddy_bambuddy_data
docker compose up -d
After that I attempted to restore the backup, which bambuddy said finished successfully. So I restarted the container, refreshed my webpage and nothing had changed. I force refreshed the page, closed browser, opened a new browser, and the settings were still the ones that were set before the restore.
So I decided to just try and set everything back up as it was manually, and when trying to add a printer, I got an error stating the printer already exists. The one printer I setup showed up and works fine. It seems as though the settings were restored, but aren't getting applied.
I should also mention that the archive states it has 1 gb of data usage, but nothing shows up in the archive.
The installation was not updated between backup and restore.
After all that, I am still having the same issue with the virtual printer as well.
#668 Is probably related to this, but there were no solutions from that issue that worked for me.

Expected Behavior

When restoring a data backup, data should be restored.

Steps to Reproduce

Detailed above in the description.

Printer Model

Not printer-related

Bambuddy Version

0.2.4b2-daily.20260504

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

Backup File: https://drive.google.com/file/d/1HjvH1STyjRAnQmWaOjQGuBbI_grHryFV/view?usp=sharing
Log File (Started debug mode > Restore Backup > docker compose restart > Download Support Bundle): bambuddy-support-20260504-150111.zip

Screenshots

No response

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 4, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1211 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description I was having issues with the virtual printer (Error 13: Permission Denied) so I created a backup and then: 1. docker compose stop 2. docker compose rm -v 3. docker volume remove bambuddy_bambuddy_data 4. docker compose up -d After that I attempted to restore the backup, which bambuddy said finished successfully. So I restarted the container, refreshed my webpage and nothing had changed. I force refreshed the page, closed browser, opened a new browser, and the settings were still the ones that were set before the restore. So I decided to just try and set everything back up as it was manually, and when trying to add a printer, I got an error stating the printer already exists. The one printer I setup showed up and works fine. It seems as though the settings were restored, but aren't getting applied. I should also mention that the archive states it has 1 gb of data usage, but nothing shows up in the archive. The installation was not updated between backup and restore. After all that, I am still having the same issue with the virtual printer as well. #668 Is probably related to this, but there were no solutions from that issue that worked for me. ### Expected Behavior When restoring a data backup, data should be restored. ### Steps to Reproduce Detailed above in the description. ### Printer Model Not printer-related ### Bambuddy Version 0.2.4b2-daily.20260504 ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package Backup File: https://drive.google.com/file/d/1HjvH1STyjRAnQmWaOjQGuBbI_grHryFV/view?usp=sharing Log File (Started debug mode > Restore Backup > docker compose restart > Download Support Bundle): [bambuddy-support-20260504-150111.zip](https://github.com/user-attachments/files/27373089/bambuddy-support-20260504-150111.zip) ### Screenshots _No response_ ### 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-07 00:14:38 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-07 00:14:39 +02:00

Author

Owner

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

Also here is my docker-compose.yml:

docker-compose.yml

@Carter3DP commented on GitHub (May 4, 2026): Also here is my docker-compose.yml: [docker-compose.yml](https://github.com/user-attachments/files/27373592/docker-compose.yml)

BreizhHardware commented

2026-05-07 00:14:39 +02:00

Author

Owner

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

So you used the same version which was running before, or do you changed the Bambuddy version/daily image?

@maziggy commented on GitHub (May 5, 2026): So you used the same version which was running before, or do you changed the Bambuddy version/daily image?

BreizhHardware commented

2026-05-07 00:14:39 +02:00

Author

Owner

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

Looked at your support package — the restore did take effect more than it looks. Your custom settings (USD, energy 0.15/kWh, HA enabled, debug logging on, etc.), your P1S printer, and the virtual printer config all came through. The "before restore" comparison is misleading because you wiped the volume first, so "before" was actually empty defaults — what you're now looking at are the restored values, which happen to match your previous setup.

The "printer already exists" when you tried to add it manually is also the restore working — that row was already in the database.

What's actually anomalous is archives: 1 row in the database vs. ~1 GB of files on disk. To pin this down I need three things:

Approximate date/time you created the backup zip, and approximate
date/time you restored it.
The version string of the instance that did the restore:
```
docker exec bambuddy cat /app/version.txt
```
(or whatever the About page shows). The :daily tag changes every day, so "docker compose up -d" after the volume wipe could have pulled a newer build than the one that made the backup, which is the same shape as #668.
The backup zip itself. If that's awkward, please unzip it locally and run:
```
sqlite3 bambuddy.db "SELECT count(*) FROM print_archives;"
sqlite3 bambuddy.db "SELECT count(*) FROM printers;"
```
and paste the numbers. That tells us whether the missing archives are missing in the backup itself or only after restore —
completely different bugs to chase.

Separately on the virtual printer Permission Denied: that's almost certainly the bind mount in your compose,
"./virtual_printer:/app/data/virtual_printer", combined with "user: 1000:1000". The host directory needs to be writable by uid
1000. Quick check / fix:

     ls -ld ./virtual_printer
     sudo chown -R 1000:1000 ./virtual_printer

Then "docker compose restart bambuddy".

@maziggy commented on GitHub (May 5, 2026): Looked at your support package — the restore did take effect more than it looks. Your custom settings (USD, energy 0.15/kWh, HA enabled, debug logging on, etc.), your P1S printer, and the virtual printer config all came through. The "before restore" comparison is misleading because you wiped the volume first, so "before" was actually empty defaults — what you're now looking at are the restored values, which happen to match your previous setup. The "printer already exists" when you tried to add it manually is also the restore working — that row was already in the database. What's actually anomalous is archives: 1 row in the database vs. ~1 GB of files on disk. To pin this down I need three things: 1. Approximate date/time you created the backup zip, and approximate date/time you restored it. 2. The version string of the instance that did the restore: docker exec bambuddy cat /app/version.txt (or whatever the About page shows). The :daily tag changes every day, so "docker compose up -d" after the volume wipe could have pulled a newer build than the one that made the backup, which is the same shape as #668. 3. The backup zip itself. If that's awkward, please unzip it locally and run: sqlite3 bambuddy.db "SELECT count(*) FROM print_archives;" sqlite3 bambuddy.db "SELECT count(*) FROM printers;" and paste the numbers. That tells us whether the missing archives are missing in the backup itself or only after restore — completely different bugs to chase. Separately on the virtual printer Permission Denied: that's almost certainly the bind mount in your compose, "./virtual_printer:/app/data/virtual_printer", combined with "user: 1000:1000". The host directory needs to be writable by uid 1000. Quick check / fix: ls -ld ./virtual_printer sudo chown -R 1000:1000 ./virtual_printer Then "docker compose restart bambuddy".

BreizhHardware commented

2026-05-07 00:14:39 +02:00

Author

Owner

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

Backup and restore were both done on the same version of bambuddy.
The P1S printer is showing up only because I manually added it, the log I posted was after I manually added the printer. There should be 8 printers total. The energy cost should be 0.12 as well.

I made the backup at almost 2 pm exactly my time (EST). I restored it the first time about 15-20 minutes later, after removing the bambuddy_data volume. I believe the restore that was in the log I sent was at 3 pm.
My about page shows v0.2.4b2. I know for a fact it was specifically 0.2.4b2-daily.20260504 as before I made the backup I checked the releases page to check for the new release, saw that one, and did docker compose pull and docker compose up -d I also got "No file or directory found" when running docker exec bambuddy cat /app/version.txt
The google drive link posted has the backup zip. heres the link again: https://drive.google.com/file/d/1HjvH1STyjRAnQmWaOjQGuBbI_grHryFV/view?usp=sharing

For the virtual printer Permission Denied, I had been looking through the issues on Friday and had already tried sudo chown -R 1000:1000 ./virtual_printer multiple times to no avail. I checked the owner from both before and after and before it was root root, but I changed it to 1000 1000, and sent docker compose restart checked again and now it is 1000 1000, but I still get Permission Denied.

@Carter3DP commented on GitHub (May 5, 2026): Backup and restore were both done on the same version of bambuddy. The P1S printer is showing up only because I manually added it, the log I posted was after I manually added the printer. There should be 8 printers total. The energy cost should be 0.12 as well. 1. I made the backup at almost 2 pm exactly my time (EST). I restored it the first time about 15-20 minutes later, after removing the bambuddy_data volume. I believe the restore that was in the log I sent was at 3 pm. 2. My about page shows v0.2.4b2. I know for a fact it was specifically 0.2.4b2-daily.20260504 as before I made the backup I checked the releases page to check for the new release, saw that one, and did `docker compose pull` and `docker compose up -d` I also got "No file or directory found" when running `docker exec bambuddy cat /app/version.txt` 3. The google drive link posted has the backup zip. heres the link again: https://drive.google.com/file/d/1HjvH1STyjRAnQmWaOjQGuBbI_grHryFV/view?usp=sharing For the virtual printer Permission Denied, I had been looking through the issues on Friday and had already tried `sudo chown -R 1000:1000 ./virtual_printer` multiple times to no avail. I checked the owner from both before and after and before it was root root, but I changed it to 1000 1000, and sent `docker compose restart` checked again and now it is 1000 1000, but I still get Permission Denied.

BreizhHardware commented

2026-05-07 00:14:39 +02:00

Author

Owner

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

Picture of ls -ld * in /var/lib/docker/volumes/bambuddy_bambuddy_data/_data/

@Carter3DP commented on GitHub (May 5, 2026): Picture of `ls -ld *` in /var/lib/docker/volumes/bambuddy_bambuddy_data/_data/ <img width="726" height="343" alt="Image" src="https://github.com/user-attachments/assets/046bf4cf-588a-4951-b007-a31f9cccd89e" />

BreizhHardware commented

2026-05-07 00:14:39 +02:00

Author

Owner

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

Re-read your support package and the energy_cost_per_kwh = 0.15 you flagged is the default that main.py:3457 falls back to when the row is missing. So the restore did fail to bring those settings across, just as you said.

Likely cause: SQLite WAL state from the fresh container start being re-applied on top of your restored DB. Live DB runs in WAL mode, so anything written before the restore call (default groups, init_db migrations, background heartbeat writes) sits in bambuddy.db-wal until checkpointed. The restore endpoint did engine.dispose() then shutil.copy2(backup, db_path) — neither of which checkpoints the WAL, and SQLAlchemy's dispose() doesn't close checked-out connections (the route handler's own db session is one). On the next open SQLite can re-apply those stale frames over the restored content, which matches your symptoms: data dirs intact (those were copied separately by shutil.copytree), most DB rows reverted to defaults.

Same shape as #668, which I closed in March without an actual fix — that user happened to make it work by rolling back to a stable release, which sidestepped the timing.

The next daily image swaps shutil.copy2 for SQLite's online backup API (src_conn.backup(dst_conn)) on the SQLite restore path. The page-by-page protocol opens both DBs as proper SQLite connections and routes new pages through the destination's own WAL — concurrent open sessions can't corrupt the restored state. Reproduced the bug
in a unit test, verified the new path returns the restored values under the same un-checkpointed-WAL condition.

Two of you have hit this in eight months and both reports are vague on the exact pre-restore state, so I can't be 100% sure this single cause covers both — there may be a second path I haven't reproduced. What I can say is the WAL-leftover failure mode does match all your symptoms and the new code path is provably safe against it. Once it's out, please give it another go and tell me what comes back:

docker compose pull
docker compose down
docker volume remove bambuddy_bambuddy_data
docker compose up -d
# wait for the container to come up, then upload your backup zip
# via Settings → Backup → Restore, restart per the UI prompt

If it still doesn't restore cleanly I want to hear about it immediately — that's data for chasing a second cause, not a "user
error".

For the unrelated VP "Permission Denied": chown ruled out the host directory. Error 13 by itself isn't enough to narrow it further — when you have a moment:

docker compose logs bambuddy 2>&1 | grep -iE "virtual|permission|error 13" | head -40

That'll show whether it's a file inside the bind mount with different ownership, an AppArmor/SELinux denial on the host, or something else (e.g. bind() on a privileged port). Happy to chase it once we know which.

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!

@maziggy commented on GitHub (May 5, 2026): Re-read your support package and the energy_cost_per_kwh = 0.15 you flagged is the default that main.py:3457 falls back to when the row is missing. So the restore did fail to bring those settings across, just as you said. Likely cause: SQLite WAL state from the fresh container start being re-applied on top of your restored DB. Live DB runs in WAL mode, so anything written before the restore call (default groups, init_db migrations, background heartbeat writes) sits in bambuddy.db-wal until checkpointed. The restore endpoint did engine.dispose() then shutil.copy2(backup, db_path) — neither of which checkpoints the WAL, and SQLAlchemy's dispose() doesn't close checked-out connections (the route handler's own db session is one). On the next open SQLite can re-apply those stale frames over the restored content, which matches your symptoms: data dirs intact (those were copied separately by shutil.copytree), most DB rows reverted to defaults. Same shape as #668, which I closed in March without an actual fix — that user happened to make it work by rolling back to a stable release, which sidestepped the timing. The next daily image swaps shutil.copy2 for SQLite's online backup API (src_conn.backup(dst_conn)) on the SQLite restore path. The page-by-page protocol opens both DBs as proper SQLite connections and routes new pages through the destination's own WAL — concurrent open sessions can't corrupt the restored state. Reproduced the bug in a unit test, verified the new path returns the restored values under the same un-checkpointed-WAL condition. Two of you have hit this in eight months and both reports are vague on the exact pre-restore state, so I can't be 100% sure this single cause covers both — there may be a second path I haven't reproduced. What I can say is the WAL-leftover failure mode does match all your symptoms and the new code path is provably safe against it. Once it's out, please give it another go and tell me what comes back: docker compose pull docker compose down docker volume remove bambuddy_bambuddy_data docker compose up -d # wait for the container to come up, then upload your backup zip # via Settings → Backup → Restore, restart per the UI prompt If it still doesn't restore cleanly I want to hear about it immediately — that's data for chasing a second cause, not a "user error". For the unrelated VP "Permission Denied": chown ruled out the host directory. Error 13 by itself isn't enough to narrow it further — when you have a moment: docker compose logs bambuddy 2>&1 | grep -iE "virtual|permission|error 13" | head -40 That'll show whether it's a file inside the bind mount with different ownership, an AppArmor/SELinux denial on the host, or something else (e.g. bind() on a privileged port). Happy to chase it once we know which. --- 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!

BreizhHardware commented

2026-05-07 00:14:40 +02:00

Author

Owner

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

I will update bambuddy as soon as the next daily build is out.
I do have to run sudo with any docker commands because I have not added permissions for running docker as the current user. Sorry for mentioning this so late.
10.1.10.137 is the raspberry pi that is running the docker container with bambuddy and 10.1.10.139 is the laptop I use to access that all.
Output of docker compose logs bambuddy 2>&1 | grep -iE "virtual|permission|error 13" | head -40
bambuddy@BamBuddy:~/Downloads/bambuddy $ sudo docker compose logs bambuddy 2>&1 | grep -iE "virtual|permission|error 13" | head -40
[sudo] password for bambuddy:
bambuddy | Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'
bambuddy | Cannot create directory /app/data/virtual_printer/certs: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'
bambuddy | 2026-05-04 14:26:59,421 INFO [root] [-] Virtual printer manager synced from database
bambuddy | Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'
bambuddy | Cannot create directory /app/data/virtual_printer/certs: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'
bambuddy | 2026-05-04 14:34:06,725 INFO [root] [-] Virtual printer manager synced from database
bambuddy | 2026-05-04 14:36:11,419 INFO [backend.app.api.routes.virtual_printers] [005e8cfc] Created virtual printer: P1S-004 (id=1)
bambuddy | INFO: 10.1.10.139:59718 - "POST /api/v1/virtual-printers HTTP/1.1" 200 OK
bambuddy | 2026-05-04 14:36:18,226 INFO [backend.app.api.routes.virtual_printers] [1a718804] Updated virtual printer: P1S-004 (id=1)
bambuddy | INFO: 10.1.10.139:59718 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK
bambuddy | 2026-05-04 14:40:49,770 INFO [backend.app.api.routes.virtual_printers] [21f1246e] Updated virtual printer: P1S-004 (id=1)
bambuddy | INFO: 10.1.10.139:59794 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK
bambuddy | 2026-05-04 14:40:54,902 INFO [backend.app.api.routes.virtual_printers] [4bee38eb] Updated virtual printer: P1S-004 (id=1)
bambuddy | 2026-05-04 14:40:54,906 ERROR [backend.app.api.routes.virtual_printers] [4bee38eb] Failed to sync virtual printers after update: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads'
bambuddy | INFO: 10.1.10.139:59798 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK
bambuddy | Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'
bambuddy | Cannot create directory /app/data/virtual_printer/certs: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'
bambuddy | 2026-05-04 15:00:59,243 WARNING [root] [-] Failed to sync virtual printers: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads'
bambuddy | Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'
bambuddy | Cannot create directory /app/data/virtual_printer/certs: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'
bambuddy | 2026-05-05 09:08:30,519 WARNING [root] [-] Failed to sync virtual printers: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads'
bambuddy | 2026-05-05 09:08:57,374 INFO [backend.app.api.routes.virtual_printers] [c3ec78b8] Updated virtual printer: P1S-004 (id=1)
bambuddy | INFO: 10.1.10.139:61032 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK
bambuddy | 2026-05-05 09:08:58,087 INFO [backend.app.api.routes.virtual_printers] [f0331ae6] Updated virtual printer: P1S-004 (id=1)
bambuddy | 2026-05-05 09:08:58,091 ERROR [backend.app.api.routes.virtual_printers] [f0331ae6] Failed to sync virtual printers after update: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads'
bambuddy | INFO: 10.1.10.139:61032 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK

@Carter3DP commented on GitHub (May 5, 2026): I will update bambuddy as soon as the next daily build is out. I do have to run sudo with any docker commands because I have not added permissions for running docker as the current user. Sorry for mentioning this so late. 10.1.10.137 is the raspberry pi that is running the docker container with bambuddy and 10.1.10.139 is the laptop I use to access that all. Output of `docker compose logs bambuddy 2>&1 | grep -iE "virtual|permission|error 13" | head -40` bambuddy@BamBuddy:~/Downloads/bambuddy $ sudo docker compose logs bambuddy 2>&1 | grep -iE "virtual|permission|error 13" | head -40 [sudo] password for bambuddy: bambuddy | Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' bambuddy | Cannot create directory /app/data/virtual_printer/certs: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' bambuddy | 2026-05-04 14:26:59,421 INFO [root] [-] Virtual printer manager synced from database bambuddy | Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' bambuddy | Cannot create directory /app/data/virtual_printer/certs: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' bambuddy | 2026-05-04 14:34:06,725 INFO [root] [-] Virtual printer manager synced from database bambuddy | 2026-05-04 14:36:11,419 INFO [backend.app.api.routes.virtual_printers] [005e8cfc] Created virtual printer: P1S-004 (id=1) bambuddy | INFO: 10.1.10.139:59718 - "POST /api/v1/virtual-printers HTTP/1.1" 200 OK bambuddy | 2026-05-04 14:36:18,226 INFO [backend.app.api.routes.virtual_printers] [1a718804] Updated virtual printer: P1S-004 (id=1) bambuddy | INFO: 10.1.10.139:59718 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK bambuddy | 2026-05-04 14:40:49,770 INFO [backend.app.api.routes.virtual_printers] [21f1246e] Updated virtual printer: P1S-004 (id=1) bambuddy | INFO: 10.1.10.139:59794 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK bambuddy | 2026-05-04 14:40:54,902 INFO [backend.app.api.routes.virtual_printers] [4bee38eb] Updated virtual printer: P1S-004 (id=1) bambuddy | 2026-05-04 14:40:54,906 ERROR [backend.app.api.routes.virtual_printers] [4bee38eb] Failed to sync virtual printers after update: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads' bambuddy | INFO: 10.1.10.139:59798 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK bambuddy | Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' bambuddy | Cannot create directory /app/data/virtual_printer/certs: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' bambuddy | 2026-05-04 15:00:59,243 WARNING [root] [-] Failed to sync virtual printers: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads' bambuddy | Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' bambuddy | Cannot create directory /app/data/virtual_printer/certs: Permission denied. For Docker: ensure the data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' bambuddy | 2026-05-05 09:08:30,519 WARNING [root] [-] Failed to sync virtual printers: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads' bambuddy | 2026-05-05 09:08:57,374 INFO [backend.app.api.routes.virtual_printers] [c3ec78b8] Updated virtual printer: P1S-004 (id=1) bambuddy | INFO: 10.1.10.139:61032 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK bambuddy | 2026-05-05 09:08:58,087 INFO [backend.app.api.routes.virtual_printers] [f0331ae6] Updated virtual printer: P1S-004 (id=1) bambuddy | 2026-05-05 09:08:58,091 ERROR [backend.app.api.routes.virtual_printers] [f0331ae6] Failed to sync virtual printers after update: [Errno 13] Permission denied: '/app/data/virtual_printer/uploads' bambuddy | INFO: 10.1.10.139:61032 - "PUT /api/v1/virtual-printers/1 HTTP/1.1" 200 OK

BreizhHardware commented

2026-05-07 00:14:40 +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.

@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.

BreizhHardware commented

2026-05-07 00:14:40 +02:00

Author

Owner

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

Restoring works now. There are a few settings that didn't get restored, I believe nothing in the network tab restored and the cost per kWh did not restore, but those are easy to set back up. Everything else restored correctly though from what I can see.
Thank you so much.

For the virtual printer stuff, I am going to make another issue so that this one is specifically about the restore function. It is issue #1215

@Carter3DP commented on GitHub (May 5, 2026): Restoring works now. There are a few settings that didn't get restored, I believe nothing in the network tab restored and the cost per kWh did not restore, but those are easy to set back up. Everything else restored correctly though from what I can see. Thank you so much. For the virtual printer stuff, I am going to make another issue so that this one is specifically about the restore function. It is issue #1215

BreizhHardware commented

2026-05-07 00:14:40 +02:00

Author

Owner

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

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

@maziggy commented on GitHub (May 5, 2026): ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware referenced this issue

2026-05-07 00:16:21 +02:00

[PR #1029] [MERGED] v0.2.3 final #1155

Rows
Columns

[GH-ISSUE #1211] [Bug]: Backup Not Restored Properly #879

Component

Bug Description

Expected Behavior

Steps to Reproduce

Printer Model

Bambuddy Version

SpoolBuddy Version

Printer Firmware Version

Installation Method

Operating System

Relevant Logs / Support Package

Screenshots

Additional Context

Checklist