Closed francop311 closed 4 months ago
Hey,
could you please post the full backblaze-wine-startapp.log
and the docker logs?
Thank you!
Attached is the backblaze-wine-startup.log
There is not much in there. I even blocked web.archive.org from my router to make sure that it does not download the pinned version, but after 4-6 hours, it still finds a way to download the latestest.
Thanks for the log! I will try to figure out what's wrong there and push a fix.
What I also noticed is that the latest file appears in the bzupdates folder every 2 hours (after the 2 hour lock file)
If I delete it, it will re-appear again...
Those 2 files are not files created by our container - those are files downloaded by the Backblaze app itself. I need to check if they are currently forcing updates to a speific version.
DISABLE_AUTOUPDATE=true
can only disable our own update function but not when Backblaze forces an update from their side.
I see.. However, I have the DISABLE_AUTOUPDATE=true flag, yet it still updates to the latest version (after a few hours). I thought it was pulling this client from web.archive.org, which is why I even blocked this URL on my router.
Anyways, if you can look into this, that would be great.
Thanks
Just to let you know, it re-updated it's self to the latest version again. If I know where the backblaze client downloads the file, then I can possibly block it from my router...
I think I figured out how to block updates from backblaze. If you block this domain on your router:
f000.backblazeb2.com
It will not be able to download the client.
So far, (over 8 hours) and the bzupdate folder is empty. The only think that gets updated in the folder is the lck file:
Wish there was another way to prevent updates.....
@francop311, I was happy to see this thread and your suggestion because I have the same problem. But when I block the domain, uninstall the 9.0.1.767 version, upload the 9.0.0.749 and install it. BZ still succeeds to updating itself to the latest 9.0.1.767.
My bzupdates folders are empty, apart from a clientversion.xml file. No bzautoupdates lck files to be found. It almost seems as if it can update in-app because in the Backblaze appdata folder I cannot find any newly downloaded installers and the one I uploaded myself is still at version 9.0.0.749 (when I redownload it and check it). It could also be that BackBlaze has multiple DL locations but that still doesn't clarify how it updates itself.
It's a mysterious case. Any ideas are welcome.
Backblaze has indeed an in-app autoupdate function but they rarely force updates. Only when there is a nasty bug which affects a larger userbase. I will try to find out what's happening here and let you guys know.
Thanks @traktuner
The reason I would like to try downgrading is because I'm trying to get past incredibly slow uploads, as reported in threads #59 and #130 (7 Mbps). I tried many things like :ubuntu22 tags, deselect throttling, reinstalling etc. I'm on a decent 200 Mbps symmetrical fiber channel network on a rather fast Intel NUC so that should do I'd say. But whatever I do, setting thread to 50, my CPU still is at 10% and my UL doesn't come above 7Mbps.
But if they only push an update this in case of nasty bugs, it might not be wise to downgrade. Do you experience any of these issues as reported in #130 and #59?
Yes, that is the reason as well for me. I have about 6 TB to transfer and with version 9.0.1.767, it was uploading at about 6-7Mbs, where if I use 9.0.0.749, it transfers at over 400Mbs.
@j-peeters regarding your bzupdates folder, it is weird that you have the clientversion.xml file. I don't get this.
Are you blocking both the following domains:
Thanks
@j-peeters I am on the latest Backblaze version and my upload speed saturates my connection (100Mbit) Are you using unraid? I have a Synology setup. I tried to debug the speed issue but as far as I can tell it's not related to our Docker container but a Backblaze app thing.
(I started this issue thread and — to offer a bit of hope — I’ve been seeing about 150mbit up for a few weeks)
On Sun, Apr 14, 2024 at 1:23 PM francop311 @.***> wrote:
Yes, that is the reason as well for me. I have about 6 TB to transfer and with version 9.0.1.767, it was uploading at about 6-7Mbs, where if I use 9.0.0.749, it transfers at over 400Mbs.
@j-peeters https://github.com/j-peeters regarding your bzupdates folder, it is weird that you have the clientversion.xml file. I don't get this.
Are you blocking both the following domains:
- web.archive.org
- f000.backblazeb2.com It is possible that it is actually using the "pinned" version and not the backblaze auto-update version.
Thanks
— Reply to this email directly, view it on GitHub https://github.com/JonathanTreffler/backblaze-personal-wine-container/issues/144#issuecomment-2054126937, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJGHKVWXJNEZ5B5XMRDPO3Y5K3P3AVCNFSM6AAAAABGEXRVQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJUGEZDMOJTG4 . You are receiving this because you are subscribed to this thread.Message ID: <JonathanTreffler/backblaze-personal-wine-container/issues/144/2054126937@ github.com>
I just got the confirmation from Backblaze that they now periodically force-update the Backblate clients to the most recent version with no possibility to downgrade. It will then auto-update again automatically.
I'm indeed on Unraid. At first, I thought they may have discovered a way to detect that files are being uploaded from a server, but a Synology is also Linux-based, I guess? So that would be the same thing. It's interesting that you have no problems on Synology, but Unraid users have.
I'll give it a last try and thereafter, I'll accept that it will take 2 months to UL everything. Subsequently, it's trickle UL anyway when the bulk is safe. Thanks so far!
(I’m also on Unraid. 150mbit up on a 350mbit connection)
On Sun, Apr 14, 2024 at 1:49 PM Jan Peeters @.***> wrote:
I'm indeed on Unraid. At first, I thought they may have discovered a way to detect that files are being uploaded from a server, but a Synology is also Linux-based, I guess? So that would be the same thing. It's interesting that you have no problems on Synology, but Unraid users have.
I'll give it a last try and thereafter, I'll accept that it will take 2 months to UL everything. Subsequently, it's trickle UL anyway when the bulk is safe. Thanks so far!
— Reply to this email directly, view it on GitHub https://github.com/JonathanTreffler/backblaze-personal-wine-container/issues/144#issuecomment-2054132918, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJGHKQPUYV5MOGLPSPHWBDY5K6SXAVCNFSM6AAAAABGEXRVQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJUGEZTEOJRHA . You are receiving this because you commented.Message ID: <JonathanTreffler/backblaze-personal-wine-container/issues/144/2054132918@ github.com>
(I’m also on Unraid. 150mbit up on a 350mbit connection)
I know, but it seems this is still an Unraid issue. We all use the same Docker image which is an Ubuntu distro and only Unraid users report those speed issues. Would be interesting if there are also reports regarding docker speed issues in dedicated Unraid forums ... Maybe there's a bug with Unraid docker networking...
I just succeeded (for a few minutes) in using the 9.0.0.749 version and the speeds were like they should. But after two minutes, BB closed itself and subsequently, it restarted with version 9.0.1.767. Speeds are slow again. It can have something to do with a problem in Unraid, but since the previous version works fine, and all my other dockers have no speed issues, it puzzles me what that could be? And since you tested it on Synology and had no issues, we're a bit stuck, I'm afraid.
Maybe a new BB update will fix it, but I'm hesitant to report the issue to BB, since servers are not allowed.
same issue as above - auto upgrade after manual downgrade. getting 0.67mbps on 5000/5000 fiber with the latest version. after downgrade it uploads as expected.
using unraid as well. has workled correctly for years until recently. the only change was a new container build and inherit after i started noticing the issue and couldn't save changes in the performance tab. anything beside auto would revert to 1 thread. it works as expected after the rebuild other than speed.
@traktuner maybe you or a colleague maintainer can find a way to lock down the BB autoupdate system (making relevant folders read only with a docker setting or so) so that we can stay in version 9.0.0.749 for a bit until someone confirms that a newer version works as it should.
@j-peeters I will definetely look into it. But it sill take some time - currently lots of other things to do..
No problem @traktuner, I'm grateful that you're willing to look into this.
Thank you again @j-peeters and @traktuner for looking into this.
The quickest way, maybe, is to create a new "flag" for the installer, something like PREVENT_BZUPDATE and in the startup script create an entry in the host file to point to 127.0.0.1 for f000.backblazeb2.com.
Just an idea.
Thanks again for all your work. Really love this project and is a life-saver...
(I’m also on Unraid. 150mbit up on a 350mbit connection)
I know, but it seems this is still an Unraid issue. We all use the same Docker image which is an Ubuntu distro and only Unraid users report those speed issues. Would be interesting if there are also reports regarding docker speed issues in dedicated Unraid forums ... Maybe there's a bug with Unraid docker networking...
Just for clarity, I am NOT on Unraid, I'm actually using Openmediavault and have the same issue. Maybe it has something to do with the linux distro?
Just for clarity, I am NOT on Unraid, I'm actually using Openmediavault and have the same issue. Maybe it has something to do with the linux distro?
No, probably some underlying config on the host system. I am using Synology and have no issues with ubuntu20 or ubuntu22.
The quickest way, maybe, is to create a new "flag" for the installer, something like PREVENT_BZUPDATE and in the startup script create an entry in the host file to point to 127.0.0.1 for f000.backblazeb2.com.
We already have the DISABLE_AUTOUPDATE flag. I will try to enhance this feature in the coming weeks that this does more things than just "not" running our own updater.
Just for clarity, I am NOT on Unraid, I'm actually using Openmediavault and have the same issue. Maybe it has something to do with the linux distro?
No, probably some underlying config on the host system. I am using Synology and have no issues with ubuntu20 or ubuntu22.
The quickest way, maybe, is to create a new "flag" for the installer, something like PREVENT_BZUPDATE and in the startup script create an entry in the host file to point to 127.0.0.1 for f000.backblazeb2.com.
We already have the DISABLE_AUTOUPDATE flag. I will try to enhance this feature in the coming weeks that this does more things than just "not" running our own updater.
I really appreciate it.
Just wanted to add that the suggestion of @francop311 might not work for all. I have blocked both sites on my router and it still succeeds in updating.
Just wanted to add that the suggestion of @francop311 might not work for all. I have blocked both sites on my router and it still succeeds in updating.
There are many more URLs ;)
I figured ;-)
Just wanted to add that the suggestion of @francop311 might not work for all. I have blocked both sites on my router and it still succeeds in updating.
There are many more URLs ;)
True. I just had to go through my DNS logs and see and compare the timestamp of when the the lck file gets updated with the actual DNS entry. I then noticed the same entry would appear at exactly the same time every 2 hours. For me, it was f000.backblazeb2.com.
There are other hosts, but it would depend where you are located and which one is closes to your location. However, a quick search pointed me to the following list: api.backblazeb2.com f002.backblazeb2.com api002.backblazeb2.com f003.backblazeb2.com api003.backblazeb2.com f001.backblazeb2.com f005.backblazeb2.com zenoimages.s3.us-west-001.backblazeb2.com blocksi-screenshots-us.s3.us-east-005.backblazeb2.com api001.backblazeb2.com api000.backblazeb2.com f000.backblazeb2.com api004.backblazeb2.com dam-novastream.s3.us-west-002.backblazeb2.com f004.backblazeb2.com s3.us-west-004.backblazeb2.com planweb-nuvemshop.s3.us-west-004.backblazeb2.com beaware-mastodon.s3.us-east-005.backblazeb2.com
I am not saying that we should block all of them, but it is worth looking into. :-)
For me, If you want to temporary stop the client from downloading the updated client, it was f000.backblazeb2.com.
Seeing the same problem for the last couple of weeks. Upload speed is stuck at 6-9 Mbps, I used to saturate my 300Mbps upload speed. I am also on unraid FYI. It does not matter how many threads I assign; it never exceeds 9Mbps. I have 96GB RAM in total; there is no issue on that side.
According to my investigations the only URL where official auto-updates are downloaded from is f000.backblazeb2.com which will be blocked by setting DISABLE_AUTOUPDATE=true
when #145 is merged.
To note: It's not necessary to block web.archive.org since this is only used for our own updater which is also completely disabled when using the above environment variable. Hope that helps!
Thanks for looking into this @traktuner. I'm not sure whether this is the whole fix, though. I have blocked f000.backblazeb2.com on the router level and just uninstalled BackBlaze from my Wine. I ULed a new 9.0.0.749 to wine and installed it. Still BackBlaze succeeded to update itself (even during the installation) to 9.0.1.767.
There was an update this morning to the BackBlaze docker and I installed that. I hope your fix is not yet pulled into that one so that there is still a chance that when it has been pulled in, the blocking works. Maybe I'm just doing something wrong, but if not, there might be another update route for BB. I'm in the EU, maybe that makes a difference.
Thanks for looking into this @traktuner. I'm not sure whether this is the whole fix, though. I have blocked f000.backblazeb2.com on the router level and just uninstalled BackBlaze from my Wine. I ULed a new 9.0.0.749 to wine and installed it. Still BackBlaze succeeded to update itself (even during the installation) to 9.0.1.767.
There was an update this morning to the BackBlaze docker and I installed that. I hope your fix is not yet pulled into that one so that there is still a chance that when it has been pulled in, the blocking works. Maybe I'm just doing something wrong, but if not, there might be another update route for BB. I'm in the EU, maybe that makes a difference.
In my testing, also in the EU, f000 is the only location I could find. I can't block any other locations other than those b2 buckets because that would also block the "real" backup traffic. The pull request is not yet merged, so there is still hope. If there is no backblaze installation present at all and you start the container it automatically downloads the pinned known-good version which is currently 9.0.1.767 If you could somehow trace exaclty which URL it's pulling the installer from, that would definetely help.
Hi @traktuner thanks a lot for your speedy responses, it makes this process a lot more fluent.
I looked at my startup log and found the following:
Tue Apr 16 10:29:48 AM Etc 2024: WINE: Enabling Virtual Desktop mode with 900:900 aspect ratio Tue Apr 16 10:29:54 AM Etc 2024: INSTALLER: FORCE_LATEST_UPDATE=false - downloading pinned version 9.0.1.767 from archive.org Tue Apr 16 10:30:05 AM Etc 2024: INSTALLER: Starting install_backblaze.exe Tue Apr 16 10:34:47 AM Etc 2024: STARTAPP: Starting Backblaze version 9.0.1.767
So, as you already wrote, that makes it go to the latest pinned version. What I don't understand though is that when after uninstall the newest version, I place a 9.0.0.749 version in the root of the drive_c with the name 'install_backblaze.exe'
In my docker settings I have also set DISABLE_AUTOUPDATE: true
Maybe I'm missing something.
Then the app behaves as it should. It does not matter if there is an install_backblaze file. It checks if Backblaze really is installed, not if the installer is present. You would manually (via docker command line) install the version you need.
Ah, okay. So I missed that crucial part. Meanwhile, I've been able to install the 9.0.0 version via wine explorer by also temporarily blocking the archive.org URL. It's now installed at version 9.0.0 and scanning my disks. So I'm hopeful it'll hold. When your fix is merged I'll remove the block and see if the 9.0.0 version will stick.
Would you mind telling me what command I type in the docker command line to install the 9.0.0 version? I'm not too well versed in docker, so I'd like to learn. And would be useful for another time. Thanks.
Would you mind telling me what command I type in the docker command line to install the 9.0.0 version? I'm not too well versed in docker, so I'd like to learn. And would be useful for another time. Thanks.
Sure!
Make sure the setup file is called install_backblaze.exe and located in the root direcotry of wine (your config folder - wine - drive_c)
When the docker container is running, start the docker shell
docker exec -it backblaze-personal-wien /bin/bash
and then
cd /config/wine/dosdevices/c:/
(to get into the installer directory)
wine64 "install_backblaze.exe"
(start the installer)
Then you should see the Backblaze installer window.
Thanks for the explanation. I saw the fix was merged. I hope that another user can confirm that it indeed doesn't auto update anymore? Then I can remove the router blocks. Thanks @traktuner
By the way, I had my installer named like you said but the auto installer didn't pick it up. Maybe a permissions issue. But it works now!
Thanks for the explanation. I saw the fix was merged. I hope that another user can confirm that it indeed doesn't auto update anymore? Then I can remove the router blocks. Thanks @traktuner
By the way, I had my installer named like you said but the auto installer didn't pick it up. Maybe a permissions issue. But it works now!
Excellent. Thanks @traktuner for the quick turn around. I thought I was the only one with the issue, glad this could help others. :-)
According to my investigations the only URL where official auto-updates are downloaded from is f000.backblazeb2.com which will be blocked by setting
DISABLE_AUTOUPDATE=true
when #145 is merged.To note: It's not necessary to block web.archive.org since this is only used for our own updater which is also completely disabled when using the above environment variable. Hope that helps!
Perfect. That is what I found as well and one other reason why I had blocked only f000.backblazeb2.com. Great that this was an easy fix ;-)
easy fix
Actually it was not "that" easy. I had to walk through all URLs separately with all known paths if there is a downloadable setup there. We don't rush things here ;)
BTW. For me the update did not work.
It seems that the entry for f000.backblazeb2.com in the /etc/hosts is not being populated, as I get a "permissions denied" when startup.sh script is trying to update the hosts file.
Hey, thanks, I will check that. For me it works, downloading the installer via cURL from that URL does not work within the container.
BTW. For me the update did not work.
It seems that the entry for f000.backblazeb2.com in the /etc/hosts is not being populated, as I get a "permissions denied" when startup.sh script is trying to update the hosts file.
Please try to add this to your docker run command:
--add-host=f000.backblazeb2.com:127.0.0.1
Hi @traktuner It's unclear to me how to add something to a docker run command in Unraid since Unraid works with a page of settings like this:
And afterward you 'just' start the container via a dropdown menu. Maybe someone knows how to do this?
Hi @traktuner It's unclear to me how to add something to a docker run command in Unraid since Unraid works with a page of settings like this
Ah yeah - can you add an environment variable (just like config) with the name (left) "add-host" and the value (right): "f000.backblazeb2.com:127.0.0." ?
Thanks! Would that be like so?
it ends up being like this:
Or do the -- in --add-host=f000.backblazeb2.com:127.0.0.1
before add-host also need to be added?
Variable is wrong (for environment variables only). You need to activate advanced mode (toggle upper left) and paste it as is into a field, I don't remember what label that field has (I have not used Unraid in quite a while), if you send a screenshot with advanced mode activated I can say which
I am trying to figure out why my client keeps getting updated to the "pinned" version every 2 hours, so version 9.0.1.767
I enabled the DISABLE_AUTOUPDATE=true flag, and when the container starts up, I see: "log_message 'UPDATER: DISABLE_AUTOUPDATE=true, Auto-updates are disabled. Starting Backblaze without updating."
However, after 2 hours, and every 2 hours afterwards, it re-downloads version 9.0.1.767 and installs it.
How do I completely disable re-installation of the client?