foz

Thanks for the kind words, and no offence taken. It’s a fair concern. A bug that’s been open since 2010 says more about that particular bug than it does about WineHQ’s bug tracker as a whole. Old reports often stick around because they’re obscure, difficult to reproduce, or simply not affecting enough people for anyone to spend time on them. It doesn’t mean they’re being ignored. What usually gets a bug moving is someone putting in the work. In this case, that’s exactly what’s I'm doing - I didn’t just file a report, I wrote the fix for the bug, following Wine’s coding and submission guidelines, along with a conformance test that’s been validated against real Windows to make sure the behaviour matches Windows itself. I sent it to wine-devel as an RFC first, then submitted the merge request. It’s passed Wine’s automated test suite, and I’m currently discussing it with the maintainers responsible for that part of the code to address any feedback before it goes in. So it isn’t sitting unnoticed in a queue. It’s under review, and I’m actively working through the process. As for pushing an update myself, that’s effectively what this is part of. The aim is to get the fix into Wine proper so everyone benefits from it instead of maintaining a separate patch. In the meantime I keep the coainer up to date. I’ve already tested it against the latest Wine point release to make sure everything still works correctly on the versions the image is built from. If for whatever reason, WineHQ declines to include th fix in their release, that's when I will consider making the patch part of this software release and maintain it myself (e.g. continue to ensure it works with the current release of Wine). While we're waiting, here’s something I’ve been working on that I’m thinking about including in a future release: It’s a live upload monitor built into the container. There’s nothing to configure. It opens a full-screen terminal dashboard showing: Live estimated upload speed. Per-file progress, including filenames, sizes and progress bars for each active upload thread. A rolling list of recently completed files, including their size and upload speed. An overview of the current backup session, with active threads, chunks per minute, session totals, and memory and swap usage. Scrollable upload viewport when lots of files are uploading, and adaptation to almost any terminal size. If that’s something you’d find useful, let me know in the thread. If there’s enough interest, I’ll include it in an upcoming release. You don't need to write a reply if you don't want to - just liking this message is enough.

Hi @kurai, thanks; the screenshot confirms the client side is healthy (you're on a valid trial), so we can rule that out. That narrows "Horse" here to the one remaining cause: the client couldn't complete its handshake with the Backblaze datacenter when you hit Sign In on the inherit. With a healthy trial, that's almost always a connection timeout rather than a block and a large backup set makes it more likely, because the inherit has to pull your existing backup state from the datacenter and that can run long enough to time out. A few of things to check first, since timeouts are often transient: Just retry the inherit a few times. A fair number of Horse-on-inherit cases clear on the second or third attempt once the state pull gets through. Make sure nothing sits between the container and Backblaze - a VPN, proxy, or DNS filter on the Docker host or connecting network can break the specific datacenter call even while normal sign-in works. Confirm that you are transferring a like-for-like OS backup - my own original backup was on a Mac Mini, so I unfortunately had no choice but to start fresh. The one advantage of this is that it discards any garbage the backup has collected over time. The only potential issue here is how long your backup takes to complete - if it goes beyond 30 days, then you may want to pay for a second license until you complete the backup and then discard the original. If it keeps throwing Horse, let's look at what it actually logged so we're not guessing. Right after a failed attempt, grab the newest transmit log (from your Unraid terminal): docker exec <your-container> sh -c 'd="/config/wine/dosdevices/c:/ProgramData/Backblaze/bzdata/bzlogs/bztransmit"; f=$(ls -t "$d"/*.log | head -1); echo "$f"; tail -150 "$f"'Post the output (feel free to redact your email/any long ID strings); the line at the failure timestamp will show which datacenter it hit and whether it was a timeout or an actual error, and that tells us whether it's something we can fix on the container side.

Progress update: root cause and fix for the ~140 KB/s upload limit For everyone following the slow-upload limitation, I've tracked it down and have a working fix. Technical write-up below. Symptom: single-stream uploads under Wine top out around 140 KB/s regardless of bandwidth. It only affects app-limited senders — ones whose send() calls keep succeeding without ever filling the socket buffer. Backblaze's uploader bztransmit uses libcurl, which is exactly this pattern, so large checkpoint uploads never finished inside the client's 600-second upload timeout. Root cause: it's a difference in socket writability reporting between Wine and Windows. On Windows, select() reports a connected TCP socket as writable whenever send() it would still accept data — i.e. as long as the send buffer has any room. Wine derives its writability from the host poll(). On Linux, POLLOUT isn't set until the socket's send queue drains below ~2/3 of SO_SNDBUF. So while the buffer is between ~2/3 full and full, Windows says "writable", but Wine says "not writable" even though sends are still succeeding. libcurl's event loop does a non-blocking select() writability check before it waits on an FD_WRITE event. FD_WRITE is edge-triggered and isn't re-armed until a send actually fails with WSAEWOULDBLOCK. On Windows, the pre-check returns "writable" and curl sends immediately; under Wine it returns "not writable," so curl falls through and blocks on WSAWaitForMultipleEvents for its full ~1000 ms timeout - once per ~64 KB burst. That's where the 140 KB/s comes from. (curl documents the underlying Windows behaviour in curl issue #6146: https://github.com/curl/curl/issues/6146.) The fix: a small change in wineserver's poll_socket() server/sock.c) — report a connected stream socket writable when its send buffer still has room (TIOCOUTQ < SO_SNDBUF), matching Windows. That's it; one block. (For the curious: I also tested the obvious-looking second theory - that Wine should re-arm FD_WRITE on every send. Turns out real Windows does not do that; it only re-arms after WSAEWOULDBLOCK, per MSDN. So that change would have made Wine less like Windows, and I dropped it. The writability fix alone is sufficient.) Validation: ws2_32:sock conformance test (the invariant "select reports writable iff send would accept data"): passes on real Windows, fails on unmodified Wine (~230 of ~660 sends reported not-writable while still succeeding), passes with the fix. Real backup, end-to-end: a checkpoint that previously hit the 600 s timeout uploaded in ~80 s under the patched build. What's next: rather than ship a privately-patched Wine in the container straight away, I've filed it upstream (Wine bug 59893: https://bugs.winehq.org/show_bug.cgi?id=59893) and sent an RFC to wine-devel proposing the server/sock.c change plus the conformance test. The one open design question is that TIOCOUTQ is Linux-specific, so I want the maintainers' steer on the mechanism before opening the merge request. If it lands upstream, the container just picks it up from a future Wine release; no fork to maintain. If they decline, I'll bundle the patched build into the image. I'll update this thread when there's movement upstream. Unrelated tip: backup stuck / "Failed to grab fourHourLock" / needs a restart to run If your backup wedges (the log spamming Failed to grab fourHourLock, or the container only backing up after a restart) on lower-RAM hosts this is almost always an out-of-memory kill, not a Backblaze fault. What happens: bztransmit gets OOM-killed mid-pass while it holds the 4-hour backup lock. The lock file is left behind, so every following pass fails to acquire it and the engine spins. Check the host kernel log - on Unraid that's the Unraid terminal (or SSH), not inside the container: dmesg -T | grep -i 'killed process.*bztransmit'If you see kills there, that's it. The engine's memory scales with the number of files it tracks - the file-id index and the "build todo list" phase can climb to 3-4GB on a large set, which is enough to get reaped on an 8GB box. Fixes, roughly in order of effect: Restart the container once to clear the stale lock and resume. Cut the tracked file count: exclude large regenerable or duplicated trees - caches, package dirs, and especially backup-archive folders, which can add millions of files from a single migration. Drop your Backblaze version-history retention to 30 days if you don't need more - deleted files stay in the index until they age out, so long retention keeps memory high. Lower the backup thread count. Each thread is another bztransmit process; with the upload fix above, a single stream is fast, so you don't need many - 1–2 is plenty on a memory-constrained box, and Automatic can over-provision. If you can, give the host more RAM. Post your dmesg output and rough file count if you want a hand narrowing it down.

Really useful find, thanks for digging into it. That CPU-load trick pushing the thread count up (50 > 81) is a great data point, and it fits something I've been investigating: I think the root cause is an issue in Wine itself, in how it wakes/schedules these upload threads, rather than anything specific to Backblaze. Rather than bake a permanent CPU-burner into startup as a workaround, I'm currently testing a Wine patch that may fix it properly at the source. Early signs are promising; I'll report back once I've validated it. It will be submitted upstream to the Wine project, hence the careful testing. Should they not want to take it, if my own testing doesn't unearth anything troublesome, I'll include a patched version of Wine in with this project. In the meantime, your stopgap is a clever one for anyone who wants to get things moving now: yes > /dev/null & to spin things up, then pkill yes once the threads have launched (and ps aux | grep bzthread | wc -l to watch the count). Appreciated!

This is the way - it just takes a while to complete, and is probably exacerbated by some issues that slow some of these processes down that I am hopefully on the path to fixing. My own installation is very large and took about 48 hours to complete this initial process. If anyone stands this up and is concerned, it is normal for this part of the process to take a while.

Thanks both, I'd popped in a simple patch to add that trailing slash, but this extra bit of information helped me track down what the actual issue was. The trailing slash is a red herring: Wine treats /drive_d and /drive_d/ identically, so that wasn't the cause (good catch on noticing it made no difference). The real issue is timing in the container's startup. The container maps your host folder to a Wine drive letter by creating a symlink (dosdevices/d:). Wine only scans its drives when the wineserver starts - and the script was creating that symlink slightly too late, after the server had already come up. Initially, the drive is not visible on the first launch. However, on the next start, the symlink already existed before the server started, so it appeared. That's why restarting the container "fixed" it. I've moved the drive mapping to run before the wineserver starts, so a mapped (or newly added) drive now shows on the first launch with no restart. It's committed and will be in the next image release. Until then, the workaround is the one you already found: after adding a drive, restart the container once.

Hi all, This is the support thread for Backblaze 64 (iamfoz/backblaze-64-personal-wine-container). What it isBackblaze 64 runs the 64-bit Backblaze Personal Backup 10.x Windows client under Wine, packaged in a jlesage GUI base image so you get a web/VNC desktop in your browser. It's a fork of @JonathanTreffler's Backblaze Personal Wine container, re-engineered for the 10.x client (which dropped 32-bit and pre-Windows 10 support). It downloads the official Backblaze client from Backblaze's own servers at install time - no Backblaze software is redistributed in the image. I've done no proper benchmarking, but the slimmed-down machine template seems snappier running on my Unraid VM. I had been reliant on the upstream project and grew concerned when there was no movement since last December to resolve the issues with the new client. I am actively using this project myself and plan to ensure it continues to operate properly as new versions of the client are released. Who it's forUnraid (and other Docker) users who already pay for Backblaze Personal Backup and want to back up their array/shares with the unlimited Personal Backup plan, instead of running it on a separate Windows/Mac machine. Some tinkering may be required if you have a complex permissions setup - this is a community volunteer project, not a commercial product. My own use case is I moved several USB-attached drives connected to a Mac Mini into a JBOD USB enclosure and then used Unraid to manage the file storage. The previous system was being backed up by Backblaze and there has been no material change in the data or volume being backed up. Installing on UnraidOption A: Community Applications (once listed): open the Apps tab, search for Backblaze (it appears as Backblaze64), and click install. Option B: Add the template URL manually: on the Docker tab, click Add Container, and paste this into the Template field: https://raw.githubusercontent.com/iamfoz/backblaze-64-personal-wine-container/main/templates/backblaze-personal-backup.xml Key settings in the template: Config (/config) → /mnt/user/appdata/Backblaze64 - persistent Wine prefix + Backblaze config. Must survive restarts. Backup Source (Drive D) (/drive_d) → map the host path you want to back up. Must be read-write - Backblaze writes a .bzvol folder into each drive's root to track it. Repeat with /drive_e, /drive_f, etc. for more locations. UID/GID default to 99 / 100 (nobody/users), which matches Unraid user-share ownership. Change only if your data is owned by a different user/group. Accessing the GUI and signing inOpen the WebUI on port 5800: http://<YOUR-UNRAID-IP>:5800(Port 5900 is also exposed for a direct VNC client if you prefer.) First-run flow: On first launch, you may see Wine setting itself up / updating for a couple of minutes - let it finish. The first screen of the Backblaze installer renders a bit rough under Wine, but it works. Type your Backblaze account email into the field and press Enter. (If the screen looks blank, hover the mouse over the white pixel in the top-left corner - it'll clear and the UI will draw.) Enter your password and press Enter. Tip: the web interface clipboard helps, but odd characters/keyboard-locale mismatches can mangle input - a long password without special characters is the most reliable. Let Backblaze analyse your drives, then click OK. Recommended: if your config folder lives inside your backup source (the default on Unraid), add an exclusion to avoid an upload loop. Open Backblaze Settings → Exclusions → Add Folder, navigate to My Computer → (D:) → appdata → Backblaze64, and click OK. As with any normal install, buy/assign a license for this computer in your Backblaze dashboard. Known limitationsCosmetic "Permission Issue … bzdata\bzreports" warning. A false positive - Backblaze's self-check misbehaves under Wine, but it writes there fine and backups run normally. Safe to ignore. amd64 only. linux/amd64 is fully supported; arm64 is not currently supported. A previous "unstyled control panel" issue (black background / blank dialogs) is fixed - the container now creates the hyphen-named skin-asset aliases at startup, so the panel renders correctly on first launch. Reporting bugsPlease search existing issues first, then open one here if needed: https://github.com/iamfoz/backblaze-64-personal-wine-container/issues PRs welcome if you find a fix; it helps everyone. CreditsHuge thanks to @JonathanTreffler, whose Backblaze Personal Wine Community Container this is forked from; to @Atemu, the project's original author; and to @jlesage for the GUI base image. Happy backing up!