FreeMan

No QR code: Oh. My. Gosh. For the longest time, I did not have SSL enabled. I enabled it a while back and had completely forgotten I'd done so. When I tried to connect manually, I was using HTTP and port 80. I just used HTTPS and port 443 and it connected. Wow...

Unfortunately, I'm still having this issue. I saw that the ControlR plugin on the server has been updated recently, as has the app, so I decided to try connecting again. I'm still getting no response from the app when attempting to connect via either Discover or Manual. I've realized that my always-on VPN (on the phone), which is supposed to pass connections to the local network unfiltered, has been sticking its nose into local connections, too. I've disabled my VPN connection, and I can pull up the WebGUI in my Firefox browser on the phone by connecting to nas.local. The ControlR app can find the server in Discover mode. However, with the VPN still disconnected, attempting to actually connect (with the proper UID/PWD - copied from KeePass, just like I used to log into the browser GUI) just gives me a forever spinning circle. I don't get any error messages back now, it just spins. Where do I go to get a QR code to attempt to connect via QR code in the app? I seem to recall having seen a QR code somewhere in the WebGUI, but can't find it now, is that the one I need?

What do the yellow check marks mean? I don't think I've ever seen that before yesterday, and I saw nothing about it on the GitHub page. (Maybe I just missed seeing it) It's also telling me Which looks like it's trying to delete from disk5, but disk 5 is the destination, not one of the sources.

That would be awesome, thanks! Please don't forget the Scatter side - give a total amount to be moved and show how much will be moved to each of the selected destination disks.

Here's a better drawing of my suggestion. Each colored box would be a separate frame. The headers would always be available in the red frame. That way, when I've scrolled all the way down to "Z", I can still click "Next" without a lot of scrolling back up. I can scroll through the Explorer in the blue frame, and as I check items, they appear in the yellow frame. The blue & yellow frames would scroll independently, so I could select movies starting with "A", "L", and "Z" in the Explorer, and they'd show at the top of the "Selected". This way, I might choose to pick 10 (more or less) random movies that exist on disk7, and move them to some other location... Additional thought: The blue & yellow frames might need a horizontal scroll. Having that dynamically appear only when needed would be the best bet, but if they need to be there all the time, that'd work, too.

I've had no permissions warnings as I've been doing the moves. Could be, I suppose, though. The most recent run did delete the empty directories. I have a couple thousand movies - I selected this movie: Then I have to scroll back to the top of the window in order to see which/how many disks it's scattered across: If the portion in the red box could be in an iframe (or similar construct - I know just enough web dev to be extremely dangerous) with a scroll bar as needed where I added a heavy green line. Obviously, the "Shares Explorer" part would be below the frame so they would scroll independently. Just had a thought - maybe the "Shares Explorer" could scroll vertically on the left side, while the "Selected" could scroll vertically on the right side.

This is an awesome tool that works about 99% for me - I greatly appreciate it! Two suggestions for you, @jbrodriguez, when you get a few minutes to do some new development. 1) When doing a Gather, make the top of the window a non-scrolling frame. That way, as I'm scrolling through more than a screen full of movies or TV shows, I can click on one way down in the "R" section and still see what disk(s) it's on so I can decide if I need to gather it up. 2) When doing a Scatter, give me some sort of idea of how many bytes I've selected to move. I may be clearing off an entire 4TB drive, but may not want to do it all in one pass. It'd be handy to know if I've selected 400MB or 400GB of data. (If things have been scattered, 20 directories may only contain a few 100s of bytes each.)

Did you have anything else reading/writing to the array at the time of the move? The instructions explicitly say not to...

That's the behavior I expected, however, that's not the behavior I'm seeing. \mnt\disk3\Movies\Movie1 Is left as an empty directory after having moved Movie1 from disk3 to disk10. As a matter of fact, I've got 179 empty directories under ..\disk3\Movies, 14 empty directories under ..\disk3\Sport and 194 under ..\disk3\TV Fortunately, Krusader makes it easy to delete them all, but still...

I'm clearing an old disk, moving files off of it. After running a number of scatter passes, I've noticed that unBalance doesn't always delete the empty directories. Am I missing something or is this expected?

Interesting. Telegraph seems to cause a cyclical dip in read speeds from ~90MB/s down to ~60MB/s down to ~20MB/s then back up to ~90. Jellyfin just causes the drives to thrash and read speeds fall to the floor. I've been running Telegraph for a few years and never noticed any sort of significant slow down because of it, but maybe it's because I just never noticed... Seems a pain to have to shut down dockers in order to get through the parity check in a reasonable amount of time, but these two aren't critical, so I can live w/o 'em for 24 hours.

Well, I shut down all my dockers and gee... now I'm running along at nearly 100Mb/s. Guess I have to rummage about and figure out what happened that they're all creating so much disk access. I never used to have to shut down dockers to get decent parity check speed, so something's changed. Thanks for pointing out the obvious. And I do still need to replace at least the one drive with reallocated sectors - at least I think it's still under warranty, so that should be a simple one.

Is there anything in the diagnostics that would indicate why my parity checks have taken such a nose dive in speed? I'm ready to pull the trigger on a new drive to replace the one with reallocated sectors, but I want to know if I need to replace any of the others before they just up and die on me...

Interesting. I've been running cache dirs for ages (since v5.x, probably earlier than that) and it's never seemed to have an impact on parity speeds like this. I may have to go have a look to see if it's been updated recently and that might be causing issues. (I run CA Auto Update and get notifications of updates, but I don't recall every one of them.) NOPE last update to cache dirs was August 2020. It's been this way for > 2 years now. I wonder if this is also what's been preventing drives from spinning down for the last several weeks. I've noticed that every time I look at the dashboard (and in every one of my 4x/day array status notifications) that all drives are spinning. I did get them to manually spin down and stay down for a little bit when I tried yesterday, but they all went back to spinning again within a few minutes. Is the reallocated sector count something to be concerned about or to just keep an eye on to make sure it's not increasing too rapidly?

Well, the next monthly parity check has rolled around and it's currently running at about 37MB/sec. As requested, here are diagnostics during the run. Also, of note, I received an error warning: Disk7 is, at least, still under warranty, but it's not one of the drives I suspected to be failing due to very slow extended SMART tests earlier. Sigh... Should have kept my eyes open during Black Friday/Cyber Monday sales for good deals on hard drives. Forgot all about it. nas-diagnostics-20221201-0642.zip

This is my most recent disk speed test from "a while ago" (prior to the addition of the 9th data drive): And here is one I just ran this morning (including my new 9th drive): The only differences I see is an extra drive making the speed dip from ~4 - ~5.5TB and that seems to be attributable to the addition of the new drive. Those 3 drives are all Seagate IronWolfs so similar behavior is to be expected.

My parity checks have never been particularly fast on my machine, usually running 22-24 hours. The check that kicked off on 1 Nov took nearly 59 hours! My presumption is that I have a failing drive. However, after running extended SMART checks on all drives, they've all returned without errors (even though 2 of the disks took > 24 hours to run). I've attached diagnostics. Anyone see anything there that looks suspect? What else should I be checking to identify why things have suddenly slowed down so much. Other than the update to 6.11.1 (6.11.2 update was pending the completion of the SMART checks, though I'm holding off for now), I haven't made any config changes, I have CA doing automatic updates of dockers/plugins, but haven't added or removed any dockers, plugins, or VMs or done anything other than read & write data to the array. nas-diagnostics-20221106-1306.zip

I had that somewhat regularly when I was running uTorrent on my Win desktop machine, especially when the machine was rebooted by Windows updates. I've not noticed it using Deluge.

Thanks, @binhex

Thanks. Self-help fail. My apologies. These all seem to be "permanent" failure modes, i.e. they'll prevent the connection from ever establishing. In my case, it will eventually connect and everything runs just fine, so those don't seem to be applicable. Am I misinterpreting what I'm reading or is there some other possible error raising it's head?

I've been running this for probably 2+ years and everything's been great. About 3-4 months ago, however, I started having issues connecting to the WebUI: The log looks like this: 2022-10-09 18:48:57,206 DEBG 'start-script' stdout output: 2022-10-09 18:48:57 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2022-10-09 18:48:57 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2022-10-09 18:48:57 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2022-10-09 18:48:57 TCP/UDP: Preserving recently used remote address: [AF_INET]209.58.163.227:80 2022-10-09 18:48:57 Socket Buffers: R=[212992->212992] S=[212992->212992] 2022-10-09 18:48:57 UDP link local: (not bound) 2022-10-09 18:48:57 UDP link remote: [AF_INET]209.58.163.227:80 2022-10-09 18:49:58,036 DEBG 'start-script' stdout output: 2022-10-09 18:49:58 [UNDEF] Inactivity timeout (--ping-restart), restarting 2022-10-09 18:49:58 SIGHUP[soft,ping-restart] received, process restarting 2022-10-09 18:49:58,036 DEBG 'start-script' stdout output: 2022-10-09 18:49:58 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning. 2022-10-09 18:49:58 WARNING: file 'credentials.conf' is group or others accessible 2022-10-09 18:49:58 OpenVPN 2.5.7 [git:makepkg/a0f9a3e9404c8321+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 31 2022 2022-10-09 18:49:58 library versions: OpenSSL 1.1.1q 5 Jul 2022, LZO 2.10 2022-10-09 18:49:58,036 DEBG 'start-script' stdout output: 2022-10-09 18:49:58 Restart pause, 5 second(s) 2022-10-09 18:50:03,036 DEBG 'start-script' stdout output: 2022-10-09 18:50:03 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2022-10-09 18:50:03,037 DEBG 'start-script' stdout output: 2022-10-09 18:50:03 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2022-10-09 18:50:03 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2022-10-09 18:50:03,037 DEBG 'start-script' stdout output: 2022-10-09 18:50:03 TCP/UDP: Preserving recently used remote address: [AF_INET]209.58.163.227:80 2022-10-09 18:50:03 Socket Buffers: R=[212992->212992] S=[212992->212992] 2022-10-09 18:50:03 UDP link local: (not bound) 2022-10-09 18:50:03 UDP link remote: [AF_INET]209.58.163.227:80 2022-10-09 18:51:03,635 DEBG 'start-script' stdout output: 2022-10-09 18:51:03 [UNDEF] Inactivity timeout (--ping-restart), restarting 2022-10-09 18:51:03 SIGHUP[soft,ping-restart] received, process restarting 2022-10-09 18:51:03,635 DEBG 'start-script' stdout output: 2022-10-09 18:51:03 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning. 2022-10-09 18:51:03 WARNING: file 'credentials.conf' is group or others accessible 2022-10-09 18:51:03 OpenVPN 2.5.7 [git:makepkg/a0f9a3e9404c8321+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 31 2022 2022-10-09 18:51:03 library versions: OpenSSL 1.1.1q 5 Jul 2022, LZO 2.10 2022-10-09 18:51:03,635 DEBG 'start-script' stdout output: 2022-10-09 18:51:03 Restart pause, 5 second(s) 2022-10-09 18:51:08,636 DEBG 'start-script' stdout output: 2022-10-09 18:51:08 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2022-10-09 18:51:08,636 DEBG 'start-script' stdout output: 2022-10-09 18:51:08 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2022-10-09 18:51:08 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2022-10-09 18:51:08,636 DEBG 'start-script' stdout output: 2022-10-09 18:51:08 TCP/UDP: Preserving recently used remote address: [AF_INET]209.58.163.227:80 2022-10-09 18:51:08 Socket Buffers: R=[212992->212992] S=[212992->212992] 2022-10-09 18:51:08 UDP link local: (not bound) 2022-10-09 18:51:08 UDP link remote: [AF_INET]209.58.163.227:80 2022-10-09 18:52:08,876 DEBG 'start-script' stdout output: 2022-10-09 18:52:08 [UNDEF] Inactivity timeout (--ping-restart), restarting 2022-10-09 18:52:08,876 DEBG 'start-script' stdout output: 2022-10-09 18:52:08 SIGHUP[soft,ping-restart] received, process restarting 2022-10-09 18:52:08,876 DEBG 'start-script' stdout output: 2022-10-09 18:52:08 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning. 2022-10-09 18:52:08,876 DEBG 'start-script' stdout output: 2022-10-09 18:52:08 WARNING: file 'credentials.conf' is group or others accessible 2022-10-09 18:52:08 OpenVPN 2.5.7 [git:makepkg/a0f9a3e9404c8321+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 31 2022 2022-10-09 18:52:08 library versions: OpenSSL 1.1.1q 5 Jul 2022, LZO 2.10 2022-10-09 18:52:08 Restart pause, 5 second(s) 2022-10-09 18:52:13,877 DEBG 'start-script' stdout output: 2022-10-09 18:52:13 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2022-10-09 18:52:13,877 DEBG 'start-script' stdout output: 2022-10-09 18:52:13 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2022-10-09 18:52:13 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication 2022-10-09 18:52:13,877 DEBG 'start-script' stdout output: 2022-10-09 18:52:13 TCP/UDP: Preserving recently used remote address: [AF_INET]209.58.163.227:80 2022-10-09 18:52:13 Socket Buffers: R=[212992->212992] S=[212992->212992] 2022-10-09 18:52:13 UDP link local: (not bound) 2022-10-09 18:52:13 UDP link remote: [AF_INET]209.58.163.227:80 Eventually, several hours later, I can connect to the UI and everything is good. If I get impatient, sometimes I can connect after restarting the container one or two times. Any suggestions on what to take a look at?

I've only got 1TB, and as noted, the DB itself is only 22GB. I was misinterpreting what I was looking at the first go round. I have from 1.6 already. Again, I appreciate all your efforts on this and don't want to appear to minimize any of the work you've put in!

Problem solved! There was some sort of issue starting the docker and it was spamming the log with its startup info. Heading off to the LS.IO support thread, I discovered that as of June, 2022, the docker has been deprecated! Since I hardly ever used it. I've stopped the docker and deleted the config. I'm now at 23GB out of 30GB used, and should be good to go for quite a while.

derp! That makes complete sense. I see that now. I glossed over that one. I'll see what I can do to trim those logs, and I may go ahead and up the img size, too. TYVM!

Note that scrutiny is listed twice so I knew I didn't miss any lines. I was pretty sure that my docker file was 30GB, and my memory didn't fail me! If UNRAID says the containers only take 20.2GB, why is it reporting that I'm at 100% img file use when the image file is 30GB?