Everything posted by quinnmjcj
-
[Support] Djoss - CrashPlan PRO (aka CrashPlan for Small Business)
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....
-
[6.6.6] Unreasonable number of writes reported
One of my disks reported a HUGE number of writes (see Main.pdf) immediately after restarting unraid. I was unmounting and remounting disk6 to rebuild it. disk5 had the large number of writes and the write errors when I mounted disk6 and restarted..... I've had this happen with disk5 a couple of times in the past. This is with stable 6.6.6 unraid - log attached. log.txt Main.pdf qnas-diagnostics-20190206-0745.zip
-
[Plugin] CA Fix Common Problems
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.
-
[Plugin] CA Fix Common Problems
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)
-
Dynamix File Integrity plugin
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......
-
Dynamix File Integrity plugin
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).
-
Dynamix File Integrity plugin
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!).