FreeMan

My preclear has finished and gave me this result: Elapsed Time: 38:46:05 ========================================================================1.22 == == Disk /dev/sdn has been successfully precleared == with a starting sector of 64 ============================================================================ No SMART attributes are FAILING_NOW the number of sectors pending re-allocation did not change. the number of sectors re-allocated did not change. SMART overall-health status = [root@e60018e2f375 /]# A) The "SMART overall-health status =" at the end seems... like something's missing. B) Seems to me there was more to the report last time I ran this, but it's been long enough I don't honestly remember. Is something missing? C) I went looking for the preclear report in /boot/preclear_reports where they used to be written, and realized the newest one is from 18 months ago, and my chat history here shows that my last preclear was only 3 months ago. Are the logs no longer written there? Where do I find them now?

Yup. I did that a couple of posts back. [emoji6] Thanks for the confirmation. Sent from my moto g(7) using Tapatalk

I just went ahead and said "Yes" to the "are you sure you want to start" question without any additional parameters. I'm about 1/2 way through the preread. I figure if it doesn't "work" properly, the server will do whatever if deems necessary when I add the drive to the array. My goal is to exercise the drive before trusting data to it, so I guess this'll do the trick. I may end up sending this dock back anyway, now that I know the problem is my case USB3 ports not working and that the old dock didn't fail. This one's got a fan, but I'm not sure it's helping, and it's got LEDs bright enough to be used as anti collision lights on the ISS.

I ran that in a PuTTY session and it correctly ID'd the disk as a Seagate IronWolf, picked up the SN, etc. It specifically says: Device is: In smartctl database [for details use: -P show] Which isn't surprising, it's not the first IronWolf I've installed in this machine. It is, however, the first time I've used this new USB3 enclosure, so that may be the issue. I tried running the preclear_binhex.sh -f /dev/sdn and it gave me the same error. I'm not sure what the appropriate next step should be...

I've just picked up a new USB dock (because it's a pain to get drives into my server since I don't have any hot-swap bays), and when I execute preclear_binhex.sh -f /dev/sdn, I get this: Pre-Clear unRAID Disk /dev/sdn ################################################################## 1.22 smartctl may not be able to run on /dev/sdn with the -d ata option. however this should not affect the clearing of a disk. smartctl exit status = 2 smartctl 7.0 2018-12-30 r4883 [x86_64-linux-5.10.21-Unraid] (local build) Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org Read Device Identity failed: Invalid argument A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.$ Do you wish to continue? (Answer Yes to continue. Capital 'Y', lower case 'es'): I, of course, aborted out of an abundance of paranoia. I've done preclears via USB doc before. As a matter of fact, I've done it on Seagate IronWolf drives before (this is another). I presume that this is a failing of this particular dock? Is it safe/recommended to continue with the preclear, especially since I'm only doing this as a pre-install test? If so, what are the '-T permissive' options, and which one(s) might I want to add?

Well, carp. It appears that my front-of-case USB3 ports are non-functional. I plugged the dock into the USB2 port and it showed right up. Now to wriggle around behind the case and plug it in the back - I am not waiting for an 8TB drive to preclear via USB2...

Updating my PuTTY client from 0.62 to 0.74 seems to have done the trick. I guess that makes the SSH updates a GoodThing™.

Close, but no cigar. I had keys to connect to my backup server stored in /root/.ssh/ along with a few lines to move them on boot, and I did move them per the linked instructions. Unfortunately, PuTTY is still throwing the same error when I try to connect to my server.

Updated my main server to 6.9.0 then 6.9.1 and have run into 2 issues that only make sense in relation to the upgrade: 1) Unassigned Devices and PreClear don't seem to be able to recognize drives plugged in via USB. I've connected both a brand new 8TB drive that I want to preclear (for testing purposes only, I know it's not required), and an older 4TB drive that's known to be good, but has been retired. It recognizes neither. UD doesn't show any devices and preclear_binhex.sh -l reports "No unassigned disks detected". I've confirmed that the USB dock I'm using works by plugging it into my Win10 machine and both of them show up in windows management, so the dock & and both drives are functional. 2) In an attempt to double check the preclear results, I tried to open a PuTTY terminal and was presented with this error message: I don't know if my version of PuTTY is seriously out of date (I haven't a clue when I last updated it) or if there's something that I need to add back in to UNRAID to get it to accept a PuTTY connection, but this is mildly frustrating. nas-diagnostics-20210311-1428.zip This is the first issue I've had with an upgrade since I transitioned to 6.x, so I'm certainly NOT complaining! I'm the one who wants you guys to fix the Windows Update process! I'm just mildly disappointed and a bit frustrated because I've got this new drive to get installed...

No worries! Just making sure. There's probably nothing critical on this disk, so it wouldn't be a crisis if I lost data, but I would rather avoid it, and I'm never afraid to double check.

There's no emulation involved - every disk appears to be mounted just fine: Would you still recommend a disk rebuild, or just acknowledge the error and keep an eye on the disk? I'll probably make myself a reminder to do an extended parity check on it at least monthly, if not weekly.

Here are the results of the extended SMART test. unRAID reports "completed without error". nas-smart-20210303-0828.zip

@JorgeB:

I'm still on 6.8.3 and would prefer to remain there until I get this resolved, if possible. The fewer pieces changing at once, the easier it should be to track down... While my parity check was running yesterday, I got this notification: Unraid array errors: 2021-03-01 22:24 Warning [NAS] - array has errors Array has 1 disk with read errors Looking at my Array devices display, I see that disk 8 is reporting 256 errors. Of course, the warranty expired on 16 Feb 2021, so I've got that going for me... The parity check finished with no indication of error whatsoever. This disk has never, it appears, had a SMART self-test run, so I ran a short-test which completed without error and that's in the included diagnostics. I've got a long test running and will post results when that finishes. If anyone can tell me if this is starting to look terminal, I'd appreciate it. nas-diagnostics-20210302-1301.zip

Did you ever get this resolved? I just picked up a ConBee II and am wondering...

Just saw the notes on the IP leak, fixes, and required config changes. I've gotta say, I was expecting to wrestle with it for a bit, but it was quick and easy to get things changed and get everything back working. Thanks for all your efforts @binhex!

OK, it seems I shouldn't have taken that exactly literally gives me an error that the repository name must be lower case and leaves me with an orphaned image. However does work. Unfortunately, before I saw SpencerJ's post, I'd fiddled with the drive dropdowns and have lost some variable settings so I'll have to reset them. Better than having to completely start from scratch. Hrmm... Maybe I spoke too soon: I get the same missing drives... Then I stopped all three dockers and restarted Influxdb > Telegraf > Grafana and all is good now. Whew!

Ah! That makes perfect sense and, yeah, I knew that. This makes sense - that's yesterday's growth, since it was all written to cache and the mover ran around 01:30 today.

Is the `Array Growth (Day)` chart designed to show new data added since midnight <My timezone>? If so, I don't think mine's working right. Here's what it's showing currently: And here's my TZ setting: I can only account for about 3GB of data added since midnight. I've checked my backup directory and have had very little added there of late. As I was typing this, I got to wondering if this shows the data added in the previous 24 hours, as noted in the TZ settings screen shot. If that's the case, why does the growth graph start at zero for a little while before climbing? Does that not show growth over the time period?

I had this working in the LE days, and seem to have successfully updated to SWAG (my certificates are updating), however, my reverse proxy setup doesn't seem to be working in one specific instance. Since originally installing LE, I've added a VPN. I have a connection for my primary desktop machine, and I have a connection that I use with my binhex-delugevpn client and I have several dockers accessing the outside world using that docker as a proxy. When I try to connect to https://emby.myddns.com, I get the default "Welcome to our server page". However, when I disconnect the VPN [i]on my desktop machine[/i] and try to access it from there, I get the login page as I would expect. If I reconnect the VPN, again, I simply get the default page again. Why would the VPN connection running on my desktop machine impact SWAG's forwarding of the connection to the server? I have confirmed that port 80 is forwarded to port 81 on my server (not 100% certain why I'd changed that originally, but all I've done is transfer my LE config files to the SWAG config directory, and it does work when the VPN connection is down). As soon as I posted the question, it decided to start working properly. I don't know if it took some time after adding the emby config file in (I'd missed doing that originally) and restarting the SWAG docker, or what, but now I'm getting my login prompt again. Now, to reset all my passwords because I'm sure nobody remembers theirs, it's been down a while.

Genius! This has been bugging me for months! I even went into the settings and told it to use the previous session and it didn't restore the selected directories. Thanks!

I simply cleared cache and did a ctrl-F5 hard reload of the page. Too bad, I was getting some decent write speeds on that drive! 🤣🤣🤣

Just updated from 1.4 to 1.5 to confirm that I'm still having this odd issue. I had replaced an older 4TB drive with a new 8TB drive, but left the old drive in the server when I booted it back up. Yes, this was a silly idea and I'm not sure why I did it, but I went ahead and added that drive to the Unassigned Drive(s) variable. I just upgraded a different 4TB to 8TB and removed both of the now unused 4TB drives (including the one that had been listed in Unassigned Drives). However, the dashboard, under both 1.4 and now 1.5 are showing a constant 301.07MB/s read rate on the Unassigned I/O graph. As I understand it, with no devices assigned to the Unassigned Drives variable, nothing should be showing here. What would you recommend I do to trouble shoot? The only customization I've done to my 1.5 install so far is to assign drives to the proper categories. I've yet to delete all the Plex stuff (I don't run it) or do any of my drive overrides to make nice names on the I/O and temp graphs. Thanks, once again, for all your efforts on this!

I will say this: It seemed like a huge jump to go from unRAID v5.x to v6.x (and I was certainly very late to that party!) but it is really, really worth it!. If nothing else, with v6 you get notifications in the WebGUI (if you don't turn on email or push notifications) of OS updates, and it's a click and about 3-4 minutes for a near flawless update to the latest release version. If only these guys worked for Microsoft, Windows updates might not be such a pain!

Of course, this is the Christmas season and it's entirely reasonable that @housewrecker has decided to take some well deserved (I'm sure) time off from developing this project, and, possibly, the internet itself, to spend some time not being a marriage wrecker (another assumption, I know). I hope we'll hear back in the next few weeks, as everyone's lives resume, and get some good news that an Emby version is in the works, but if not, well, I've lived without this thus far, and will continue to live without it in the future.