razorslinky

Updated the both ui_info and ui.properties and still having issues connecting Here's some logs from the docker Crashplan: Thanks for this! Have you been able to find a direct download link for Windows 64 bit version as well? Just tried to download the x64 version and it appears that they haven't posted it yet. https://download2.code42.com/installs/win/install/CrashPlan/jre/CrashPlan-x64_4.3.0_Win.exe https://download2.code42.com/installs/win/install/CrashPlan/jre/CrashPlan-x64_4.4.0_Win.exe

Figured it out... reviewed the logs in C:\ProgramData\CrashPlan\log\ui_Administrator.log.0 Updated .ui_info to look like this: port, guid, unraid ip And now the GUI connects to the crashplan headless docker

Just downloaded and installed the windows client: https://download.code42.com/installs/win/install/CrashPlan/jre/CrashPlan_4.4.0_Win.exe The Crashplan (gfjardim/crashplan:latest) version is showing as 4.4.1 Updated the both ui_info and ui.properties and still having issues connecting Here's some logs from the docker Crashplan:

Just wanted to update everyone since moving from ReiserFS to XFS. It's been a few weeks and everything has been running smoothly. Here's my uptime which is unbelievable for me: 09:17:36 up 8 days, 2:04, 2 users, load average: 4.27, 4.34, 3.91 I'm officially calling this and will mark this topic as [sOLVED-WORK-AROUND]

Razorslinky, Thanks so much for your commitment to sorting this out. I'd recommend changing the topic to [WORK-AROUND] if bitrot runs fine though. The problem still exists, and since ReiserFS is the default filesystem, any new users will be plagued by this problem. Hopefully LimeTech can resolve the problem or prompt the ReiserFS maintainer to resolve it, but if not, this work around should help any that encounter the problem we're having. Marking it as solved makes it seem like it's no longer an issue, which could result in people not reading the entirety of the post. Now I have to buy another 3TB drive I guess. I've updated the topic to [WORK-AROUND] for now. So far, I've been running the Mover script everyday at 7am. I rebooted my server so I had to stop the bitrot script but it was at 25% when I stopped it. I'm feeling very confident that MY issue has been resolved due to moving the filesystem to XFS. I would really like to thank EVERYONE for helping and troubleshooting my issue. I know this is not the place for a suggestion but I think that in the future Limetech should get rid of ReiserFS completely. I really don't trust that filesystem after reading about other people having the same issue.

So far... everything is looking amazing. I've been manually copying over 50GB of data to the cache drive and manually running the Mover script. No issues or lockups have occurred. Bitrot script is running against 15TB of data and so far its gone through 10%. I'm going to be very optimistic here and say that the issues have been resolved. I'll wait until the bitrot script is finished to change my topic to [sOLVED].

Mover moved 100GB worth of data without any issues and now bitrot is running and hasn't had any issues so far. If bitrot successfully completes then my issue has been resolved and can be blamed on ReiserFS.

Finally migrated ALL 30TB (13 disks) from ReiserFS to XFS with NO write errors reported. I am running Mover right now and if that's successful I will attempt to run the bitrot utility and see how it works. I will keep everyone updated!

This is exactly what I was going to say. Did you ever run Unraid 6.0 beta6 and/or 7? Those two version had the reiserfs bug (in the kernel not from unraid) which toasted the filesystem. I've had data corruption and kernel locks all the time, while running Mover or even writing data to /mnt/user.. I'm slowly moving all of my data from reiserfs to XFS and feel pretty confident that it's a reiserfs issue since I've never had one issue copying data to any newly formatted XFS drive. So far I've copied about 15 TB from reiserfs to XFS using the following command under Screen (so I can close the putty session): "rsync -arv --stats --remove-source-files --progress /mnt/disk5/ /mnt/disk7/" (some of the arguments might be redundant but I've had really good success this way) Here's my post with a ton of information and determining it's a reiserfs issue: http://lime-technology.com/forum/index.php?topic=35788.0

Oh good call... I'll add to that my todo list. Also found out when stopping the array, unraid froze and had a kernel panic on the "syncing filesystem" line.. which means that there's still some underlying issue with a reiser filesystem on one of the disks still. 2 disks converted to XFS, 11 more to go.

That's more than enough validation for me. This is going to be a long road of syncing, deleting, verifying, etc.. but I'm feeling hopeful that this will resolve all of my "mover / filesystem" issues.

After reading all of the blogs, reviews, etc... it seems like BTRFS is amazing on paper (as in some people compare it to ZFS but not as mature and/or feature rich) but when it comes down to it, it seems like people are having some weird issues.

Go XFS for now. That's the plan. Just wanted to see if I was missing anything with BTRFS.

Alright... Well here's my progress so far: Moved everything off disk3 and onto another computer and formatted the disk to XFS. After formatting it XFS, I ran the scrub command for ~30 minutes just to see if it would crash, and it actually kept going. When running scrub with ReiserFS, Unraid would crash within 2-3 minutes. So I rsycned another drive to Disk3 and so far it's written 1.45 TB and has 2,801,338 writes on it so far. And it's going strong, averaging between 50-90 MB/s. I think all of my crashing has to do with the ReiserFS corruption issue. So I'm now in the process of converting every drive I have to XFS. I'm very tempted to do BTRFS instead but I'm a little hesitant since it's still considered "experimental." I love living on the bleeding edge but I don't think I want to deal with any BTRFS issues anytime soon. Anyone here want to chime in about XFS vs BTRFS?

Not sure if you want to test this but what happens if you run bitrot against the actual disk... /mnt/disk1/$SHARE? This will bypass the shfs mounting method and write straight to the disk itself.