[[Plugin] ControlR]

On 4/2/2022 at 4:34 PM, jbrodriguez said:

the app does an mdns/avahi lookup in the discover tab, the ip you see there is what it gets back ?

 

can you add the server as http instead of https ?

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?

[[Plugin] unbalanced]

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

Quote

skipping:deletion:(rsync command was flagged):(/mnt/disk5/TV/Emergency!/Season 07)

Which looks like it's trying to delete from disk5, but disk 5 is the destination, not one of the sources.

[[Plugin] unbalanced]

18 hours ago, jbrodriguez said:

ok, i get it now, if i get some free time i'll take a look at it

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.

[[Plugin] unbalanced]

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.

[[Plugin] unbalanced]

8 hours ago, jbrodriguez said:

maybe a permission issue ?

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.

 

8 hours ago, jbrodriguez said:

can you provide an example ?

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.

[[Plugin] unbalanced]

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.)

 

 

[[Plugin] unbalanced]

1 hour ago, Steviewunda said:

So 500GB of music files have gone? Fool that I was, I was consolidating my shares to make backup to another Unraid server easier - the successful dry runs convinced me that it was safe to run Unbalance. As always, it pays to backup before making changes. Unfortunately, I could never trust that Unbalance was going to perform correctly again.

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

[[Plugin] unbalanced]

3 hours ago, jbrodriguez said:

it doesn't delete top level directories (the Unraid shares), other than it should delete folders under the share that are empty 

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...

[[Plugin] unbalanced]

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?

[Painfully slow parity check - dying drive?]

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.

[Painfully slow parity check - dying drive?]

42 minutes ago, JorgeB said:

First thing to do it to stop anything else accessing the array and see the difference it makes.

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.

[Painfully slow parity check - dying drive?]

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...

[Painfully slow parity check - dying drive?]

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?

[Painfully slow parity check - dying drive?]

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:

 

Quote

Unraid Disk 7 SMART health [5]:

Warning [NAS] - reallocated sector ct is 8

ST8000NM005-1RM112_ZA1FS9VW (sdn)

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

[Painfully slow parity check - dying drive?]

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.

[Painfully slow parity check - dying drive?]

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

[[Support] binhex - DelugeVPN]

On 10/13/2022 at 10:45 AM, bobobeastie said:

Is anyone else having an issue where you can manually recheck finished files and the files are found to be incomplete?  I have had to recheck/downloads up to 3 times in a row at times.  I have seen the percent done go from 100% to 80% on some files.  I'm seeing very noticeable glitches in video files downloaded through deluge.  UnRaid isn't reporting any issues with my array/fs.  It started around a month ago, seemed to get better, but is now worse for me.

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.

[[Support] binhex - DelugeVPN]

Thanks, @binhex

[[Support] binhex - DelugeVPN]

2 hours ago, binhex said:

see Q17 :- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

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?

[[Support] binhex - DelugeVPN]

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:

 

Quote

Firefox can’t establish a connection to the server at 192.168.1.5:8112.

 

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?

[Ultimate UNRAID Dashboard (UUD)]

On 7/1/2022 at 9:24 PM, falconexe said:

I have a 2TB cache drive

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.

 

On 7/1/2022 at 9:24 PM, falconexe said:

If you don't like the Plex panels, feel free to remove them

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!

[[Solved] Docker IMG file is at 100%]

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.

[[Solved] Docker IMG file is at 100%]

3 minutes ago, trurl said:

You also have to add in the other 2 column totals.

derp! That makes complete sense.

 

4 minutes ago, trurl said:

Looks like scrutiny logs are pretty large

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!

[[Solved] Docker IMG file is at 100%]

20 minutes ago, trurl said:

Go to Docker, click Container Size at bottom, post screenshot

 

 

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?

[Ultimate UNRAID Dashboard (UUD)]

It's got NOTHING to do with what I thought it did...

 

I had a totally unrelated docker going crazy with log files growing to > 7GB of space. That docker's been deprecated (any wonder why), so I shut it down and deleted it.

 

I've just hit 100% utilization of my 30GB docker.img file, and I think I've nailed the major culprit down to the influxdb docker that was installed to host this dashboard. It's currently at 22.9GB of space.

 

Is anyone else anywhere near this usage? Is there a way to trim the database so that it's not quite so big?

 

I'm trying to decide whether I want to keep this (as cool as it was when it was first launched, it's wandered into a lot of Plex focus on later updates and, since I'm not a Plex user, they don't interest me, plus I've grown a touch bored with this much info overload), or if it's time to just scrap it.

 

I totally appreciate the time and effort that went into building it and @falconexe's efforts and responsiveness in fixing errors and helping a myriad of users through the same teething pains. I'm just not sure it's for me anymore...