quinnmjcj

Had the following issue on rc-4 (didn't try any of the previous 6.80rc builds): Can't run any .py or .sh script (didn't try an executable) on the boot flash. Couldn't execute the go script, or any of my own scripts. They all worked again immediately as soon as I reverted to 6.7.3rc4. If you really need diags - I'll go back to 6.80rc4 to run them, but there was nothing helpful in the logs that I could see, and the permissions on all the folder and files looked correct.

Just curious if I'm the only one who can't get Crashplan to restore a file larger than about 900 MB. I've worked with Crashplan, and they've been no help in resolving the issue. It constantly tries to download the file, but then it stops, and says destination unavailable. I'm about to cancel my crashplan subscription, since if I can't restore anything, it's not very helpful. I've also tried restoring using Windows, and get the same problem....

That wasn't my issue - I understand that - what I don't understand is why it says the port is not available or changed, when it is available.

I'm getting: Docker Application Sonarr_lnxio, Container Port 8989 not found or changed on installed application Docker Application Sonarr_lnxio is currently set up to run in host mode Docker Application NZBGet_lnxio, Container Port 6789 not found or changed on installed application Docker Application NZBGet_lnxio is currently set up to run in host mode Docker Application binhex-couchpotato, Container Port 5050 not found or changed on installed application Docker Application binhex-couchpotato is currently set up to run in host mode If I change to Bridge mode, both warnings go away, but the fact is, in host mode, the port works correctly - I use <address>:5050 on my local net to get to couchpotato and it works fine. Not a big deal, but seems kind of wierd. (version 2017.04.14)

If the option "When parity operation is running" is set to "Don't start" then the verification tasks won't start if parity is running at the time. Once the verification tasks are started they can't be terminated. This is also true for a parity check which kicks in afterwards. My advice: schedule the parity check and verification tasks in such a way that they can't interfere with each other. That's not my point - I shut down the server and restarted it to rebuild a data disk that had died - I had "don't start" set - but it still started - so clearly, the plugin doesn't consider rebuilding a data disk the same as a parity rebuild, and it should......

Even after shutting it down (i.e. setting "search for new files" or whatever it's called to NO", it continued running multiple find commands - I finally had to uninstall the plugin to get it to stop - if I killed a find, it just started back up..... It really needs to stop entirely when parity operations are going on (at least, if that's what I ask for).

An issue I just ran across - I have "when parity operations are running" set to Don't start. But I'm rebuilding a data disk, and it started update new files - it really shouldn't do that, since that's a parity operation as well (it's really slowing down my rebuild!).