anna

@foz testing build 199: pinning to client 10.0.1.1069 resolves the lock-up issue as predicted. i can also confirm that on the same build and client 10.0.3.1075, the process runs cleanly from STARTBACKUP through TransmitFilesInOneTodoFile with no lock error. running the bz transmit grep command shows: INFO: BZT_C13: TransmitFilesInOneTodoFile: successfully called BzEncryptWithRSAPubK FindFirstEmptyPodParcel_DoNotBlock (processId=636) called by TransmitFilesInOneTodo two suggestions: running bb-doctor on my now working install same day as lock-ups occurred, it reports: [FAIL] the client lost its four-hour lock 6 times in the current log; no backup pass completes the lock file is on disk and the client's own check says it is not. Client 10.0.3.1075; seen with 10.0.3.1075 under Wine. set BACKBLAZE_VERSION=10.0.1.1069 on the container and restart: the pinned version is installed over the newer one. i think it'd be worth tweaking this behavior so that once the issue is resolved, bb-doctor reports that afterward, just for clarity's sake? maybe that's just me though. other thing i wanted to report is that on my end, log timestamps don't seem to follow the docker TZ variable. i have TZ="Europe/Berlin" set, but logs are consistently 2 hours behind. no big deal, just thought to mention it. regarding your question @rogman / @YourNekoWaifu honestly, your guess what file deletion exactly fixed it is as good as mine. i had client version 10.0.3.1075 pinned to beta build 181 which did still lock up, just as @foz predicted, but wiping most of the bzdata folder (aside from bzinstall.xml and a few other required files) and giving it a fresh start did the trick temporarily. especially now that a new build is out and given you can nuke your install don't replicate just because it worked on my end, please. the new build is safe to upgrade to :) thank you @foz for your great work and taking the time to investigate.

I have been battling the Lost four hour lock error around Producing file lists for the past 3 days. I attempted: manually creating an empty lock file, as reccomended by @Shadowrunner restarting, updating and restoring from an appdatabackup renaming all files related to the Todo andtransmit processes (mostly .dat files) to .bak and let Backblaze recreate them run bb-doctor with --fix multiple times many, many times of letting it produce file lists before it immediately locks up again Container Image: beta build: version=beta build: revision=52a80851b6819e0ebeff94dc635df7d313d242c3 build: build=181 build: variant=beta-ubuntu26 build: built=2026-09-14T10:00:08Z Wine: wine-11.14 Backblaze client Installed: 10.0.3.1075 Available: 10.0.3.1075 (via ca000) Status: up to date@foz any help is greatly appreciated. Let me know if you need one of the various diags. edit: resolved, backup is running again (for now), but it seems like this error can come up again anytime, if a shutdown is somehow unclean and with lock file. backblaze64-diag-202609172259.zip

Thanks so much for this plugin. I've installed it on 7.1.4 to replace theme engine before updating to the newer OS. It worked flawlessly even on this earlier build and I had a smooth update to 7.2.2. The unraid team should mention this as a replacement for theme engine since a good portion of us just used a custom css file. FYI if anyone has issues with their dashboard looking different after updating to 7.2, these changes lie in /webGui/styles/themes/black.css. For example, if you previously had a different background color defined for your dashboard elements, setting --mild-background-color: initial !important; in the root of your CSS fixes this.

Similar situation here, I updated the unraid connect plugin and it broke the theme engine plugin entirely. Only a clean install of theme engine helped.