On 7/24/2026 at 9:27 PM, rogman said:

I've been reading up on this fix Foz has made; it looks amazing, and I very badly need it since I'm trying to back up an initial 14TB, but I fear the wait could be months for his merge to be accepted if it does. So I talked with AI to help implement this patch, and it generated a script you can run in the container. I have run it and confirmed the server/sock.c file is using the modified one. From initial testing, my uploads still seem to be sitting at around 10mbs which is horrible with 1gb fiber. However, maybe this will work better for others. It's possible I didn't do something right, but I pulled the merge straight from the git page.

If this is not allowed to be posted here, then please remove it, and I apologize. I know there are many other frustrated people out there waiting on uploads.

Create a /scripts/ folder in the containers root appdata folder and save the script there as "patch-wineserver.sh", then in your Unraid terminal just run [docker exec Backblaze64 /config/scripts/patch-wineserver.sh]

######start script#######

#!/bin/bash

#

# patch-wineserver.sh

#

# Rebuilds wineserver from Wine 11.0 source with the fix for WineHQ

# bug 59893 (upload speed capped at ~140 KB/s under Wine — libcurl

# apps like Backblaze's bztransmit) and installs it in place of the

# container's stock wineserver.

#

# USAGE (run inside the Wine container, as root):

# docker cp patch-wineserver.sh CONTAINER_NAME:/tmp/patch-wineserver.sh

# docker exec -it CONTAINER_NAME bash /tmp/patch-wineserver.sh

#

# Safe to re-run any time — e.g. after the container restarts and

# reverts to the stock wineserver. It rebuilds from scratch each run

# and will not overwrite a good backup with an already-patched binary.

set -e

echo "==> Installing build dependencies..."

apt-get update

apt-get install -y --no-install-recommends \

git build-essential flex bison pkg-config mingw-w64

echo "==> Fetching Wine 11.0 source..."

rm -rf /tmp/wine

git clone --branch wine-11.0 --depth 1 https://gitlab.winehq.org/wine/wine.git /tmp/wine

cd /tmp/wine

echo "==> Setting a throwaway git identity (needed for cherry-pick to commit)..."

git config user.email "patch-script@localhost"

git config user.name "patch-wineserver script"

# Exact commit for MR !11272 / bug 59893 ("server: Report a stream socket

# writable while its send buffer has room."). Pinned by SHA rather than a

# branch-range diff — with a shallow wine-11.0 clone, comparing two branch

# tips has no shared history to work from and silently pulls in years of

# unrelated changes instead of just the fix.

FIX_COMMIT="35952c3f"

echo "==> Fetching the fix branch (to pull in the exact commit)..."

git fetch https://gitlab.winehq.org/foz/wine.git sock-writable

echo "==> Applying the exact fix commit ($FIX_COMMIT)..."

if ! git cherry-pick "$FIX_COMMIT"; then

echo " cherry-pick hit a real conflict — falling back to a scoped diff of server/sock.c"

git cherry-pick --abort || true

git show "$FIX_COMMIT" -- server/sock.c > /tmp/sock-fix.patch

git apply /tmp/sock-fix.patch

fi

echo "==> Configuring (64-bit only, skipping unrelated optional libs)..."

./configure --enable-archs=x86_64 CROSSCC=x86_64-w64-mingw32-gcc \

--without-x --without-freetype --without-vulkan --without-opengl \

--without-gstreamer --without-pulse --without-alsa --without-oss \

--without-cups --without-sane --without-usb --without-udev \

--without-dbus --without-gphoto --without-krb5 --without-gettext

echo "==> Building wineserver..."

make -C server

if [ ! -f server/wineserver ]; then

echo "ERROR: build did not produce server/wineserver — check the output above."

exit 1

fi

echo "==> Installing patched wineserver..."

WINESERVER_PATH="$(which wineserver)"

if [ ! -f "${WINESERVER_PATH}.orig-backup" ]; then

cp "$WINESERVER_PATH" "${WINESERVER_PATH}.orig-backup"

fi

rm -f "$WINESERVER_PATH"

cp server/wineserver "$WINESERVER_PATH"

chmod +x "$WINESERVER_PATH"

echo "==> Stopping any running wineserver so the new one takes over..."

pkill -9 -x wineserver || true

echo "==> Done. Patched wineserver installed at $WINESERVER_PATH"

echo " Original backed up at ${WINESERVER_PATH}.orig-backup"

#######end script#########

Somehow I cant get this to work - but might be me that is stupid

5 hours ago, gandalf15 said:

Somehow I cant get this to work - but might be me that is stupid

Did you save everything from the start script line to the end script line and paste in notepad or some text editor, save it with a .sh extension, then move it to your appdata backblaze folder in a new folder called scripts? The most important part is that once you get your file on your Unraid machine as .sh, you have to make it executable. You can use Krusader or the terminal for that with this command "docker exec Backblaze64 chmod +x /config/scripts/patch-wineserver.sh"

2 hours ago, rogman said:

Did you save everything from the start script line to the end script line and paste in notepad or some text editor, save it with a .sh extension, then move it to your appdata backblaze folder in a new folder called scripts? The most important part is that once you get your file on your Unraid machine as .sh, you have to make it executable. You can use Krusader or the terminal for that with this command "docker exec Backblaze64 chmod +x /config/scripts/patch-wineserver.sh"

I did, i chmod to +x, changed owner to nobody:users, when I try to launch the script it gives me the following:

root@Igor:~# docker exec Backblaze64 /config/scripts/patch-wineserver.sh

exec /config/scripts/patch-wineserver.sh: exec format error

btw: I do it from bash in unraid, not inside the docker.

Edited July 31Jul 31 by gandalf15

10 minutes ago, gandalf15 said:

I did, i chmod to +x, changed owner to nobody:users, when I try to launch the script it gives me the following:

root@Igor:~# docker exec Backblaze64 /config/scripts/patch-wineserver.sh

exec /config/scripts/patch-wineserver.sh: exec format error

btw: I do it from bash in unraid, not inside the docker.

patch-wineserver.shhere is the file, maybe something didn't save right when you created it. Also this script now includes the patches that you just posted about too. However I'm still getting only 15-25Mb/s upload speeds total with 21 streams

Edited July 31Jul 31 by rogman

1 minute ago, rogman said:

patch-wineserver.shhere is the file, maybe something didn't save right when you created it

Thanks, there seems to be a lot of more lines in it than what was posted?

1 minute ago, gandalf15 said:

Thanks, there seems to be a lot of more lines in it than what was posted?

I updated it with that second fix you found so it does both patches

I also just have the script file in appdata/Backblaze64/scripts then I created a user script in Unraid user scripts and run it from there. That script is just

Edited July 31Jul 31 by rogman

Ok Thanks - let me try it now. I will reply in a couple of minutes

Ok that worked now.

There was a lot of output lines. Thank you for your help @rogman

Do I restart the docker now? It seems that the vnc connection is frozen (within browser).

Also do I have to run it after every restart?

Just now, gandalf15 said:

Ok that worked now.

There was a lot of output lines. Thank you for your help @rogman

Do I restart the docker now? It seems that the vnc connection is frozen (within browser).

Also do I have to run it after every restart?

yes just restart the container. Should only need to run if the container updates. All those output lines was it recompiling wineserver

5 minutes ago, rogman said:

yes just restart the container. Should only need to run if the container updates. All those output lines was it recompiling wineserver

Thank you - it is currently producing the file list - that might take some time though. I will report back if it runs faster now - Thank you very much for your help!

Edit: So far "Last file transfered speed: 0.71 Mbits/sec". I also did the yes command to put load on it after restart - it has 93 threats now running. More I cant say yet. Lets hope it works!

Edited July 31Jul 31 by gandalf15

@gandalf15 I don't know how reliable the last file transferred is inside the app, but if I watch my server bandwidth, I get between 10-25mb/s. Works out to around 100GB/day or more. I don't know what else to do to get the 35 or 75 mb/s per thread (I only get 22 threads with it set to 50) that the guys who wrote the patches get, since the script pulls in their exact code. But I'm not a coder, just good at navigating Claude to make it happen.

@gandalf15 So, after further digging, there is a script when you launch the container that looks like it might be patching the file back to the original on boot, so here is how to get around that. Put that original script file in the Backblaze64 root appdata folder along with this new script 90-patch-wineserver.shpatch-wineserver.sh

Then run this in the Unraid terminal

• - - - - -

docker cp /mnt/user/appdata/Backblaze64/patch-wineserver.sh Backblaze64:/config/scripts/patch-wineserver.sh

docker cp /mnt/user/appdata/Backblaze64/90-patch-wineserver.sh Backblaze64:/etc/cont-init.d/90-patch-wineserver.sh

docker exec Backblaze64 chmod +x /etc/cont-init.d/90-patch-wineserver.sh

docker exec Backblaze64 chmod +x /config/scripts/patch-wineserver.sh

• - - - - -

Then restart the container; this adds a new startup script to install the patch as the last startup script, so it will, in effect, install the patch every container restart.

Edited August 1Aug 1 by rogman

3 hours ago, rogman said:

@gandalf15 So, after further digging, there is a script when you launch the container that looks like it might be patching the file back to the original on boot, so here is how to get around that. Put that original script file in the Backblaze64 root appdata folder along with this new script 90-patch-wineserver.shpatch-wineserver.sh

Then run this in the Unraid terminal

• - - - - -

docker cp /mnt/user/appdata/Backblaze64/patch-wineserver.sh Backblaze64:/config/scripts/patch-wineserver.sh

docker cp /mnt/user/appdata/Backblaze64/90-patch-wineserver.sh Backblaze64:/etc/cont-init.d/90-patch-wineserver.sh

docker exec Backblaze64 chmod +x /etc/cont-init.d/90-patch-wineserver.sh

docker exec Backblaze64 chmod +x /config/scripts/patch-wineserver.sh

• - - - - -

Then restart the container; this adds a new startup script to install the patch as the last startup script, so it will, in effect, install the patch every container restart.

Good morning - I will try that now then. I was going to say so far it isnt really faster on my end :)

I will report back - Thank you very much!

Edit: runs and works, I see in the startup log now the same messages. Lets see over time if it does something faster. I have sadly a lot of dockers run that eat bandwith - so I cant really say from dashboard what comes from the backblaze container. So far at least I dont see a difference :S

Edited August 1Aug 1 by gandalf15

I think we are at the mercy of the professionals on this one...

16 hours ago, rogman said:

I think we are at the mercy of the professionals on this one...

All good - the https://github.com/JonathanTreffler/backblaze-personal-wine-container/tree/main one is updated since an hour ago

Edit: Spun up the updated Jonathan Treffler docker, inherited the backup and now: Last file transfer speed: 4.43 Mbit/sec. Seems that really fixxed the slow upload problem - hurray!

Edited August 2Aug 2 by gandalf15

12 hours ago, gandalf15 said:

All good - the https://github.com/JonathanTreffler/backblaze-personal-wine-container/tree/main one is updated since an hour ago

Edit: Spun up the updated Jonathan Treffler docker, inherited the backup and now: Last file transfer speed: 4.43 Mbit/sec. Seems that really fixxed the slow upload problem - hurray!

I tested it out, and it's running at 250-300 Mb/s (from Unraid's network stats). So then I ran the original patch-wineserver script that patches Foz's fix in, and now it's running at 500-650 Mb/s

Edit: I also get 76 threads as is

patch-wineserver.sh90-patch-wineserver.shHere are the patch files. Then I put them into the root folder and ran

docker cp /mnt/user/appdata/Backblaze_Personal_Backup/patch-wineserver.sh Backblaze_Personal_Backup:/config/scripts/patch-wineserver.sh

-- you have to manual create that scripts folder

docker cp /mnt/user/appdata/Backblaze_Personal_Backup/90-patch-wineserver.sh Backblaze_Personal_Backup:/etc/cont-init.d/90-patch-wineserver.sh

I still am super grateful for what Foz and others have done here, if only they could link up and smash this out of the park!

Edited August 2Aug 2 by rogman

6 minutes ago, rogman said:

I tested it out, and it's running at 250-300 Mb/s (from Unraid's network stats). So then I ran the original patch-wineserver script that patches Foz's fix in, and now it's running at 500-650 Mb/s

That sounds very promising. Do I understand you right, you took the JonathanTreffer container and on top did your own script?

5 minutes ago, gandalf15 said:

That sounds very promising. Do I understand you right, you took the JonathanTreffer container and on top did your own script?

yes I took that new container and ran the original Foz fix that pulls in his merge request. I posted the files above and steps. Works like dream

A quick update, and firstly, apologies that this release has taken a little longer than planned. The usual life pressures got in the way, although I have been working on it on and off over the past few weeks.

I have spent most of this weekend completing the remaining updates, bug fixes and security work, followed by smoke and CI testing and dogfooding the new image myself to make sure everything behaves as expected in a real installation.

This is a fairly substantial release. Without spoiling the full announcement, it adds:

• Backup-aware container health reporting

• Optional recovery from known stall conditions

• A live terminal upload monitor

• Improved version reporting

• Installation diagnostics

• A safe way to produce sanitised support bundles on demand

There has also been a considerable amount of hardening behind the scenes, particularly around recovery behaviour, diagnostic privacy and preventing broken images from being published. The final burn-in tests are running now after they caught a couple of minor issues that I wanted to correct rather than knowingly ship. Assuming nothing else appears, I expect the release to drop tomorrow.

Wine upload-speed patch

I am still not entirely comfortable shipping a patch before it has been properly reviewed and merged upstream into Wine. However, there is clearly a significant appetite both for the fix and for a straightforward way to try it without rebuilding Wine or injecting scripts into a running container. I will therefore provide an explicitly labelled beta image based on Ubuntu 26.04 with the patch already baked in. It will be easily selectable alongside the two stable release channels (Ubuntu 24, Ubuntu 26).

Upcoming Backblaze client release

I am also aware of an upcoming Backblaze client release that may introduce compatibility issues because it includes a newer version of cURL. As soon as Backblaze begins serving that build, I will test it against the Backblaze64 container and make any changes needed to maintain compatibility.

More details, upgrade guidance and the full changelog tomorrow.

@foz Any chance you can bake in the fix from @TessyPowder into the beta build since together your fixes are pure magic?

Yes, that is essentially what I am doing today, though it will end up as one change rather than two bolted together.

The slow upload has two separate causes and you need both fixed to get full speed.

The first is that Wine tells the application a socket is not writable when it is. Linux only reports a socket as writable once its send queue has drained well below the buffer size, whereas Windows says writable whenever there is any room at all. cURL (within Backblaze) believes Wine and stops sending. I tracked that down, filed it as Wine bug 59893, and submitted the fix as merge request !11272. It has been with the Wine developers for several weeks now. That fix is what is already in my beta image, and on my own hardware it took a real backup from about 1 Mbit/s to about 72.

The second is a deadlock. Once Wine has told the application "you can write", it stops watching the socket for writability at all. If the application then hits a genuinely full queue and waits for the next writable notification, nothing is left watching, so the wait runs to its full timeout even though the socket drained milliseconds later. A Wine maintainer spotted this gap while reviewing my merge request and left it open as an unsolved problem.

I had actually built a fix for that half back in the spring and dropped it, because when I tested it against a real Windows machine the behaviour did not match Windows and I was not prepared to submit something that made Wine less accurate, and it would have likely been rejected anyway. That is why it is not already in the MR.

I have now come back to it with a version built on what I learned from the socket work. It acts only when the send queue is genuinely full, which is the state Windows treats as a failed send, rather than acting every time Linux declines to report writability, which, as above, happens routinely while there is still plenty of room. The result is that the recovery path only runs when it is actually warranted, and in the common case, the application never stops sending in the first place.

Today's job is to build Wine with both halves, run the socket conformance suite before and after, stand up a Windows machine to confirm the second half matches real Windows, and check nothing else regresses. If Windows behaves the way I expect, both halves go to the Wine developers as a single change and into the beta image at the same time, so there'll be no more waiting for you guys if you run the beta image.

I would rather this landed properly in Wine than lived on as a patch in one container. It is broken for everyone running a Windows networking application under Wine, not just us.

Quick update while I'm mid-testing: the deeper test run has turned up a problem, so this is taking longer than planned.

While putting both halves of the fix through Wine's full socket test suite, I found a case where my writability change can leave a blocking send waiting forever. Backblaze itself doesn't use sockets that way, which is why weeks of real backup testing never showed it; the client polls rather than blocks, and that path is fine. But it's a real defect, and I'm not shipping a combined beta until I understand it fully and have it fixed properly.

Currently narrowing down exactly which conditions trigger it and whether it was present from the start or exposed by a newer Wine. I'll report back with the fix, and the Wine reviewers will get the full write-up either way.

Short version: the speed fix works as well as ever for backups, I've caught something in testing that nobody else has hit yet, and I'd rather be slow and right than fast twice.

---

Thanks @foz for the update. We will wait then.

Thanks for your work on this project!

Following up on my last post, where I'd said testing had turned up a problem. It turned into quite a bit more than one, and the short version: the beta image is now published and carries the reworked fix, it's faster here than anything I'd measured before, and the answer to combining the two fixes turned out to be more interesting than just yes or no.

The problem my testing found was in my own patch. The way it measured send-buffer room could, right at the point where the buffer fills, report a socket as writable when a send would actually block. Backblaze never hits that path, which is why months of real backups never showed it. Wine's own socket test suite does hit it, and deadlocks on it, every time. Not shippable.

Digging into why led somewhere better. Wine disagrees with itself about what "writable" means: the answer it gives applications comes from one place, and the decision about whether to even attempt a blocking send comes from another, using a stricter rule. The reworked fix uses the kernel's own definition (a socket is writable exactly when a send would be accepted) and applies it in both places. It heads back to the Wine reviewers next: I'll be updating my open submission once it has been through their test service across the Windows versions I can't spin up myself. On correctness, the numbers are already solid: Wine's full socket suite passes with fewer failures than an unpatched build, and the same tests pass on Windows Server 2022 and 2025 with zero failures. Once the updated submission is up I'll post the links here for anyone who wants the nuts and bolts of the actual changes.

On combining it with the other fix, I tested that properly, including building the second half and running the test on real Windows. When a socket stops being writable without a send failing, Windows never re-signals it, so making Wine do so would be a divergence, and it's not going in. In principle, once writability is reported correctly the speed should all be there without it. In practice, that's exactly what I want your help confirming.

Which brings me to the ask. On my connection, the new beta sustains around 79 Mbit/s, the best I've measured from any version. That's one line, one host, one backlog. It's also one workload shape: what's uploading here right now is 160 MB files, which Backblaze splits into 16 chunks of 10 MB, so per-chunk round-trip times may be what's capping my number rather than the socket path. Once the multi-GB files in my backlog start moving, I'd expect it to climb. The new :beta is published now: same tag, pull again and restart (on Unraid, the Repository field is ghcr.io/iamfoz/backblaze-personal-wine:beta). If you run it, I'd like numbers: rough speed before and after (bb-monitor in the container console shows it live), your thread count, your connection speed, and roughly what size files you're uploading. Especially if you'd compiled my earlier patched Wine yourself and swapped it in, or built an image with the other fix. If any setup is faster with the re-arm than with this, that's important data, and I want to see it rather than argue with it.

The update also picks up a container fix: a stale lock left by a hard restart could wedge uploads in a way that looked healthy to every check. The container now detects that, and with the watchdog enabled, clears it itself.

If you'd rather not run the beta, v10.2.0 is out today as a stable release and carries everything else from this round. The highlights:

• bb-monitor: a live upload dashboard in the container console showing speed, per-thread file progress, recently completed files, and memory gauges

• Backup-aware health: the Unraid Docker page now shows unhealthy when the backup is actually stalled, not just when a process dies

• Self-healing (opt-in): set ENABLE_WATCHDOG=true and the container clears stale locks and restarts deadlocked upload threads on its own

• bb-doctor: checks the install against every problem this project has hit, and --fix repairs the safe ones

• bb-report: builds a diagnostic bundle for bug reports with file names hashed, so nothing private leaves your box

The beta only adds the Wine speed fix on top. The full list is in the changelog on the GitHub releases page.

Thank you @foz up and running. First scan through - eventhough it said that all discs were disconnected and had to do a full rescan, it knew what was already uploaded (I switched to the other docker image since they had a fix earlier). I will be away in a few hours for a a couple of days - try to report back. I used the beta image.