mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 05:35:30 +02:00
[GH-ISSUE #1211] [Bug]: Backup Not Restored Properly #879
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy#879
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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
@Carter3DP commented on GitHub (May 4, 2026):
Also here is my docker-compose.yml:
docker-compose.yml
@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):
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:
(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:
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:
Then "docker compose restart bambuddy".
@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.
docker compose pullanddocker compose up -dI also got "No file or directory found" when runningdocker exec bambuddy cat /app/version.txtFor the virtual printer Permission Denied, I had been looking through the issues on Friday and had already tried
sudo chown -R 1000:1000 ./virtual_printermultiple 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 sentdocker compose restartchecked again and now it is 1000 1000, but I still get Permission Denied.@Carter3DP commented on GitHub (May 5, 2026):
Picture of
ls -ld *in /var/lib/docker/volumes/bambuddy_bambuddy_data/_data/@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:
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:
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!
@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 -40bambuddy@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
@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:
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) 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:
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.
@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
@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!