jbrodriguez

Hi, the dry-run checkbox will be enabled after you finish the PLAN step. I can't remember why I made this decision back then, seeing how it's a frequently asked question now

Yes, docker safe new permissions tries to make sure you have permissions to move content around. Do note that unbalance works at a disk level, not user share level, so you will be moving data from /mnt/diskX to /mnt/diskY (for example)

I guess you could run manual rsyncs or do it via mc (midnight commander).

Can you click on the folder containing those folders (one level up) or that doesn't work for you ?

Hi, I'm not really sure what you mean. Can you post an example ?

Hi sleep depends on the s3_sleep plugin, you should have that installed. Other than that, can you check the logs for any issue regarding sleep, it should start with getfeatures:sleep:

Hi, it seems like there's an issue with the ipmi sensor. Can you post the output of /usr/sbin/ipmisensors --comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data Also can you check that /boot/config/plugins/ipmi/ipmi.cfg is present ?

Just wanted to confirm that the app will not remove the top-level folder, as it is a user share. I believe Unraid would recreate it if needed, but, by design, the app won't delete it.

It's working for me on the latest app version and 6.8.3, I'll double check later today and post back the findings.

The main concept here is that unbalance should be the only tool writing to the target drive during its operation. If you can make sure that's the case while running other tools (such as plex, mover, etc), then you should be fine.

Yep, there seems to be something wrong, after you hit plan, it should open a 'console' to show the operation progress. Can you check the developer's console for any errors ?

I think internally rsync may spawn a couple processes. I would check the source drive status with the drive speed plugin mentioned in the top banner

Hi, if you're writing to disks that are targets of an operation, the calculations will(may) be off. Let's say disk3 is the target, had 1Tb free when unbalance calculated free space, but then you write 600Gb to this same disk via mover or some other tool. So unbalance starts writing to disk3 thinking there are 1Tb free, when there are actually only 400gb free. That would be the main issue.

Hi, thanks for the suggestion. I can consider that for a future release.

Hi, thanks for the heads up. Which Unraid version are you using ?

Hi, This has happened before when the plugin can't find the Unraid webUI at the given port (443 in your case). Is it possible you added a reverse proxy to your setup (letsencrypt or similar). Also, can you try changing the ssl settings of your server. Set it to either no or yes (depending on your needs) and restart the plugin to check if that helps.

Not an expert on ssl certificates, but the error says you're accessing the server via an ip address while the certificate is built for a hostname (RVC-NAS.local). I'd guess try that ?

Yes, the websocket that manages traffic between the server side of the app and the ui is having certificate issues. Which Unraid version are you running ? I just tried on the latest Firefox and Unraid 6.8.3 and it's working fine. Do you have self-signed certs ?

Hi, the PLAN button should show a ton of additional logging. Can you check the dev tools in Chrome, to see if there's any error there ?

Hey ! Thanks a lot for the kudos ! 👍🏼

That makes sense. Yes it can get chatty if you have a lot of folders, it's transferring the whole state of the operation to update the UI. I've had a couple of ideas on how to improve that, but not enough time Also, that was brought up before by another user and that's where the refresh time setting came from.

Wanted to add a comment regarding UD .... it's definitely not trivial, as the app's logic assume the disks are part of the array. It's doable, but it'll take some time, I'll do it piecemeal.

Yep, pretty much what jbat66 said. The underlying rsync currently can only move data between /mnt/{diskX,cacheX} drives, it doesn't hit the network at all.

I'm not sure on how to fix the sensor readings 🤷🏻‍♂️ I thought I had made some changes to prevent the app from exiting, I'll need to revisit that.

I remember this happened a while back. It would seem like there's an issue with the system sensor readings. Can you try /usr/bin/sensors -A and post back the output