Shadowrunner

Could that be part of the problem, it's looking for the wrong lockfile as the one that's there is from 3 days ago? Can you get the unhashed logs for the correct filename and check whether there is one in your restored /config? Does the filename match, if not can you rename?

@rogman Not an expert on this, so Foz may say I'm talking rubbish, but it looks like your container restarted overnight and auto updated the client which seems to have deleted the lock file. The new client is trying to refresh a lock rather than create a new one, so it looks for a lock file which isn't there and gets stuck in a loop. You could try a clean restart of the container (if you haven't already), or manually creating an empty lock file to see if that wakes it up (back up /config first). I think the .lck file needs to go into /config/wine/drive_c/ProgramData/Backblaze/bzdata/bzbackup/, you'll need to check the original un-hashed logs to get the correct filename though.

Just upgraded from 6.11.5 to 6.12.1 with no issues. No so much a bug as an irritant, but since the update, everything I upload to the array has the executable bit set. It's easy enough to remove with chmod of course, but it's a pain to have to do this for everything. Is this normal in the new version or have I missed a setting somewhere? Thanks, SR

Looks like github has caught up, it;s installed ok now. Thanks for looking into it so quick. SR

Still the same, I'll try it again tomorrow. SR

Tried that, but still getting the bad MD5 error. SR

Just had an update for the Cache Dir plugin appear on the plugins tab (although it's dated from April), it's reporting a bad MD5 when I try and update though and it's killed the plugin. I've tried removing and reinstalling both from Community Applications and manually but get the same error. Any suggestions? Thanks, SR

Running this on 6.5 with no issues.

Looks like that's sorted it. Thanks for the quick response. SR

I'm getting the same, although only since the latest update to the docker. Wasn't a problem before that. SR

@johmei I'd accepted at that point that I was going to have to re-upload everything anyway so may have just clicked through, but I don't remember getting any warnings. Sorry SR

I switched over and my full 17TB migrated without having to re-upload anything, I'm not alone in this either. SR

It did that on me too. CP support told me it was just because the migration hadn't completed yet. I left it overnight and all was fine the next day. I'd try leaving it for a bit and see if it comes back. If not, or if it's already been a while I'd log a ticket with support. They've been pretty good in the past when I've needed them, even running with an unsupported headless installation. SR

Just migrated to the Pro version, docker updated ok. Also - Having fully expected to re-upload my 17TB, the whole lot migrated over without having to re-upload a single byte. I've confirmed this is correct with Crashplan support as I didn't want any nasty surprises if something had gone wrong. This might not be the case for everybody, but it looks like the 5TB migration limit isn't that rigid. SR

If you're extracting .rar files on a protected array drive, it will be slow as it needs to update parity as it goes along. With the files on a cache drive (SSD or otherwise) it should be pretty quick as there's no parity to consider. I've not used Krusader, I have Unrar installed as part of the NerdPack plugin and run it from the command line. SR