jbrodriguez

Are you accessing the server via https? If no, can you set SSL to 'no' and give it a try (stop/start the plugin after changing the setting).

The logs shows the chosen disk(s) and which data is being sent to each disk, in the planning step. It's located at /boot/logs/unbalance.log I'll take a look at it if you send it over (pm if you prefer).

That could be one way to do it.

If you reinstall it, does it work ?

I haven't unable to find the root cause for this. It seems to happen when running a reverse proxy on the server (a letsencrypt docker or similar). Is that your case ?

It doesn't 'balance' data across drives. Scatter will use all the free space on the drive with the most available space, if there's still content left to move, uses all the free space from the drive with the second most available space and so on.

Looks like you have SSL 'on'/'auto', so you should use the SSL port (443 by default). You can check for some other common issues in the FAQInsert other media

That's reasonable, I'll try to add it in the next release.

Hi, You have pretty much tried every fix for the issue. My main server is on 6.7.0 and I can access it, so I don't think version is the issue here. Would you mind following the instructions at https://github.com/jbrodriguez/controlr-support ? I'll be waiting for your email, and we'll take it from there.

Thanks for the detailed write up ! I'll process it and post back.

I know very little about hard links and their effect, but rsync has a hard-link option, that you can add as a custom rsync argument in the settings page. I just don't know if that would fix your use case.

I haven't installed 6.7.1-rc1 myself, but based on the changelog, the app should support it.

Yes it supports pause/resume parity checks.

v4.10.0 is available on the App Store / Play Store ! This release brings official support for Unraid 6.7.0+ All previous 6.7.x RCs are now unsupported.

You're absolutely right and thanks for the confirmation of the solution ! So for anyone with this issue, there are 2 options: edit /boot/config/plugins/unbalance/unbalance.conf, to remove lines that start with notifyCalc, notifyMove and rsyncFlags remove /boot/config/plugins/unbalance/unbalance.conf altogether, but you'll lose any custom settings

Thanks for the reply d2dyno. I recently removed from the code a flag that I had deprecated a long time ago, but it looks like it's still present in users' config file. Try either one of these: - edit /boot/config/plugins/unbalance/unbalance.conf, remove the line that starts with notifyCalc - remove /boot/config/plugins/unbalance/unbalance.conf altogether, but you'll lose any custom settings. Then try to stop/start the plugin from the webUI. Let me know if that works.

Upgraded to 6.7.0 and unbalance is running normally. root@lucy:~# uname -a Linux lucy 4.19.41-Unraid #1 SMP Wed May 8 14:23:25 PDT 2019 x86_64 Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz GenuineIntel GNU/Linux root@lucy:~# ps aux | grep unbalance nobody 4808 0.0 0.3 107864 10324 ? Sl 10:06 0:00 /usr/local/emhttp/plugins/unbalance/unbalance -port 6237 root 5199 0.0 0.0 3908 2228 pts/0 S+ 10:10 0:00 grep unbalance So, for those having issues, try this on the command line killall unbalance /usr/local/emhttp/plugins/unbalance/unbalance -port 6237 This is to check the output. Post the result.

Oh hadn't read the last post. Maybe an issue with 6.7.0 ? Strange, I'll upgrade my test server today and check.

Can you reinstall the plugin ? I think the plugin has a bug when Unraid upgrades major (and minor) versions, I think. Let me know.

The speed is impacted by a read/write on the same array (since every rsync command goes through parity), whereas writing from another workstation (or similar) doesn't have the same penalty, so you can even reach wire speeds (with a cache drive). Another source of slow down could be disk health. Even if SMART reports are fine, the drive could still be slow. Check this docker

I could check for mover, but other dockers would be difficult.

That's the purpose of the `rmsrc` button. The app can't automate that because it has to be a user decision.

You were actually running `basically` the same command twice. The app copied the folder, but the underlying rsync failed to set some file's date/time. The rsync command you ran should have shown the same warnings for the same file(s).

Currently, no. Move, right now, is: copy, check the folder actually exists on the target, delete the source. Verify is a VERY expensive operation, since it compares checksums of each file on the source and the target. You can do it with unbalance, by doing a COPY, then going to the History screen and clicking on the Validate button.

So, I also want to thank all of you making donations. I can't find a way to thank individually, so ... this is my thanks ! 🙌