jbrodriguez

Awesome ! The most important thing is not to 'disturb' the source or destination disks by moving/copying/etc files/folders, so that the replay works with the same initial conditions (rsync will skip over files that it has already copied)

I'd say you have SSL set to auto. If that's the case, what happens is: - unRAID creates a self-signed certificate to enable https access on the server - unRAID redirects http to https internally So you can access unRAID stock gui via http and have no issues. This may have changed in later releases, but I haven't had the time to fully check it yet. What happens on the plugin side is: - unBALANCE detects the SSL set to auto, and the presence of the self-signed certificate - unBALANCE listens on https instead of http Since you're now connecting to an https endpoint with a self-signed certificate, the browser raises the warnings.

Hi, currently not possible. This has been brought forward before and general consesus is that it wouldn't really speed transfers up, assuming you have parity on. Thanks for the kind comment !

I misread you then. Although AnnabellaRenee87 did manage to get it working. Do you have a bookmark to the plugin ? If you do the same, change http to https, does it work ?

Oh, and yes move is implemented as copy/delete.

In the history tab of the app, provided you haven't run any operation, you should see your scatter/move interrupted. Then a list of all the rsync commands that were executed, the stopped one and those that are pending to be run. You can either replay the operation, so it runs to completion or manually remove the files on the source disk (via mc or similar). Or did you have a single rsync command running ?

well, glad to know it's working for both of you

KeithG, what _Shorty said You can also set up notifications in the plugin settings (enabling unRAID notifications first). Notifications are sent for end of planning stage, start/end of transfer operations.

Thanks for the kind comments ! Glad it wasn't an issue with the plugin

Hi, could you send me /boot/logs/unbalance.log ? I'll take a look.

v2018.06.05 (5.2.1) is out ! - Fix calculation of space in the planning stage - Fix wrong command icon in history screen jj666's issue was a bug I introuced switching from int64 to uint64 in the code: at one point it subracted min. reserved space from disk's free space, which resulted in a negative number that wrapped around uint64's capacity, thus EB. The solution was switch back to int64: they're still capable in the foreseeable future As for Gico's, I made a small change: only the most recent operation in the history screen can be replayed, validated or have one of its flagged command be able to remove the source. There was some logic that I think was causing confusion as to what icon (or button) to show. As always, I'll appreciate the feedback.

Hadn't hit this bug, I'll take a look.

Have never seen EB ? Could you send me /boot/logs/unbalance.log ?

hi binky, definitely a head scratcher ... 6.5.2 should work fine in either iOS or Android. A couple of questions: - Is your ssl set to auto or yes ? - Do you have any system wide adblocker in iOS ? - If you're on ssl auto/yes, have you added the server via the secure switch on the app ? Let me know , to further troubleshoot.

I need to recreate my test server as part of rebuilding my dev environment. I will check this out in more detail.

I believe ssl = auto is the default setting in 6.5.x. Internally it redirects from http to https, so even if you connect to unRAID's webgui via http, you'll be redirected to https. unBALANCE interprets ssl = auto (and the presence of an ssl certificate) as https, so it only listens on https. The open web ui link in the plugin settings reflects that. Now, if you have a bookmark or type directly the address for unBALANCE, over http, in these scenarios, you'll get an error. I guess I could redirect http-to-https. Not sure exactly which steps you followed, but I you replayed the operation (from the history screen) or managed to 'recreate' the same set of commands for the operation from the scatter screen, then it's intended behaviour. The fast transfer speeds are due to rsync itself skipping content that was already copied.

Thanks dannen ! Not sure about this, I have a very standard html5 header in index.html <!doctype html> <html lang="en"> <head> <meta charset="utf-8"> ... I will do some research on the subject.

A quick note ... I've had an issue with my workstation, so I'm recreating my development environment. With regards to GDPR, the app uses Fabric (https://get.fabric.io/) Answers and Crashlytics modules, whose Privacy and Security policies are described here: iOS https://docs.fabric.io/android/fabric/data-privacy.html Android https://docs.fabric.io/apple/fabric/data-privacy.html (they're the same) The current version of the app uses the following SDK versions for Fabric (core framework), Answers (app events) and Crashlytics (app crashes): - iOS Fabric 1.7.5 (changelog: https://docs.fabric.io/apple/changelog.html#fabric) Answers 1.3.6 (changelog: https://docs.fabric.io/apple/changelog.html#answers) Crashlytics 3.10.1 (changelog: https://docs.fabric.io/apple/changelog.html#crashlytics) - Android Fabric 1.4.2 (changelog: https://docs.fabric.io/android/changelog.html#fabric) Answers 1.4.1 (changelog: https://docs.fabric.io/android/changelog.html#answers) Crashlytics 2.9.1 (changelog: https://docs.fabric.io/android/changelog.html#crashlytics) I've never used Twitter's Mobile App Conversion Tracking by Answers and the app doesn't use Fabric's Beta Module. The device data collected by the app via Answers (anonymized by a sha512 hash of the device's id) is: - id ( b952bbd2023142e04f32c538ed7... ) *can't visualize the full hash - manufacturer (Apple / samsung / etc.) - model ( iPhone 8 / Pixel 2 XL / etc ) - device_id ( iPhone8,1 / msm8989 / etc ) - system_name ( iOS / Android / etc ) - system_version ( 11.3.1 / 8.0.0 / etc ) - bundle_id ( io.jbrodriguez.controlr ) - app_version ( 3.6.0.66 / 4.0.0.67 / etc ) - device_locale ( en-US / de-DE / etc ) - device_country ( US / GB / etc ) These are the closest to personal data, but as mentioned before they're anonymized and help a lot with crash reports and general usage metrics. Other events, such as docker action, spin, power, etc, are also anonymously tracked and these really help in specific usage metrics. I'll update the app's privacy policy when I publish the new release, reflecting this. For the time being, if you're not ok with this info, please uninstall or do not purchase. I'll be looking into opt-in/opt-out behavior in a not so distant release.

Could you check in Edge's dev console for any errors ?

Hi, not sure about this. Could you open Firefox's web console (tools/web developer/web console) and check for any error ?

Hi, it shows the logs for the docker service, not for individual dockers. Maybe that's what you're referring to ?

ivanf, these are the relevant log lines I: 2018/05/14 21:43:49 planner.go:157: Running gather planner ... I: 2018/05/14 21:43:49 planner.go:352: scanning:disk(/mnt/disk1):folder(Downloads) I: 2018/05/14 21:43:56 planner.go:381: items:count(6):size(2.95 TB) I: 2018/05/14 21:43:56 planner.go:352: scanning:disk(/mnt/disk2):folder(Downloads) I: 2018/05/14 21:43:56 planner.go:381: items:count(1):size(219.05 GB) I: 2018/05/14 21:43:56 planner.go:352: scanning:disk(/mnt/cache):folder(Downloads) I: 2018/05/14 21:43:56 planner.go:381: items:count(2):size(5.02 GB) I: 2018/05/14 21:43:56 planner.go:505: disk(/mnt/disk1):fs(reiserfs):no-items:currentFree(39.05 GB) I: 2018/05/14 21:43:56 planner.go:505: disk(/mnt/disk2):fs(reiserfs):no-items:currentFree(2.78 TB) I: 2018/05/14 21:43:56 planner.go:505: disk(/mnt/disk3):fs(reiserfs):no-items:currentFree(3.00 TB) I: 2018/05/14 21:43:56 planner.go:505: disk(/mnt/disk4):fs(reiserfs):no-items:currentFree(3.00 TB) I: 2018/05/14 21:43:56 planner.go:505: disk(/mnt/disk5):fs(reiserfs):no-items:currentFree(3.00 TB) I: 2018/05/14 21:43:56 planner.go:505: disk(/mnt/cache):fs(btrfs):no-items:currentFree(470.91 GB) You're trying to gather the Downloads share into a single disk, but there's not enough space in any of your disks to do so. A consolidated Downloads folder would be approx 3.17Tb (2.95Tb + 219Gb + 5Gb) Your largest disk is 3Tb, so it can't fit the whole Downloads share into a single disk.

If you have your unRAID server as a network map in Windows or a Mac, it would be the flash share, so flash/logs/unbalance.log. You could also scp from a mac or windows (putty).

Hi ivanf, can you send me /boot/logs/unbalance.log to check it out ? (pm if you prefer) As for https, if your unRAID's SSL is set to 'yes' or 'auto', the plugin will listen on https.

Ok, the plugin will listen on https if ssl is set to yes or auto. It will work if you connect via https rather than http.