Fiservedpi

im currently on Nvidia 6.8.3 and do not want to update to beta

and that will handle the NVidia drivers for 6.9? that's awesome

You make it sound So easy! Thanks.

may i message you when im ready to manually apply drivers? im quite lost

perfect ty i tend to stay away from the Betas

TY I figured there was a write up on it after reading the Nvidia thread

I just noticed the thread was retired has anyone else seen this when just browsing to the plugin

Still have no clue where 16tb of movies went though

Boom! You got it I mis-mapped downloads\ in Plex earlier

Alright I'm back i have no idea why but there somehow was created an "downloads\" on multiple disks had to go through each disk to delete it lost all my movies but whatever it's back to normal now

tower-diagnostics-20200824-1548.zip

After deleting the /config/shares/downloads.cfg my web ui is back to normal but I've got no user shares. Should I restore from a backup?

Ok ty

messed up my shares now i cannit access the shares from web ui need a little help tower-diagnostics-20200824-1354.zip

I ended up re-formatting the drive from BTRFS to XFS and seems to be ok now https://wiki.unraid.net/UnRAID_6/Storage_Management#Reformatting_a_drive

pretty sure this is whats happening root@Tower:~# smartctl -a -d nvme /dev/nvme0n1 smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Number: WDS250G3X0C-00SJG0 Serial Number: 190556804076 Firmware Version: 102000WD PCI Vendor/Subsystem ID: 0x15b7 IEEE OUI Identifier: 0x001b44 Total NVM Capacity: 250,059,350,016 [250 GB] Unallocated NVM Capacity: 0 Controller ID: 8215 Number of Namespaces: 1 Namespace 1 Size/Capacity: 250,059,350,016 [250 GB] Namespace 1 Formatted LBA Size: 512 Namespace 1 IEEE EUI-64: 001b44 8b44521406 Local Time is: Sat Aug 22 19:40:41 2020 EDT Firmware Updates (0x14): 2 Slots, no Reset required Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test Optional NVM Commands (0x001f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Maximum Data Transfer Size: 128 Pages Warning Comp. Temp. Threshold: 80 Celsius Critical Comp. Temp. Threshold: 85 Celsius Namespace 1 Features (0x02): NA_Fields Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 5.00W - - 0 0 0 0 0 0 1 + 3.50W - - 1 1 1 1 0 0 2 + 3.00W - - 2 2 2 2 0 0 3 - 0.0700W - - 3 3 3 3 4000 10000 4 - 0.0025W - - 4 4 4 4 4000 45000 Supported LBA Sizes (NSID 0x1) Id Fmt Data Metadt Rel_Perf 0 + 512 0 2 1 - 4096 0 1 === START OF SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED SMART/Health Information (NVMe Log 0x02) Critical Warning: 0x00 Temperature: 37 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 0% Data Units Read: 12,929,240 [6.61 TB] Data Units Written: 25,303,344 [12.9 TB] Host Read Commands: 175,332,187 Host Write Commands: 323,863,517 Controller Busy Time: 493 Power Cycles: 2,795 Power On Hours: 8,211 Unsafe Shutdowns: 79 Media and Data Integrity Errors: 0 Error Information Log Entries: 18 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Error Information (NVMe Log 0x01, max 256 entries) No Errors Logged Mr. Blacks response seems in line with what is happening and your findings when trying to perform an SMART test from CLI i get this

Ok ty I'll keep an eye on it thanks again for your time.

Assuming no raid setups or anything exotic, it's really just that easy! Just make sure disk 1 gets assigned to where it was before in the UI and so on I just took a screenshot. I went from gigabyte A320M to Asus X370 last month with no issues whatsoever, I believe since everything is stored on the USB changing hardware is a breeze

Yeah everything is functioning correctly was just worried this all happened after a integrity check, thank you for looking at my diagnostics. Running a parity check now showing 4376 errors with "write corrections" enabled, the parity found errors issue has happened before (only after beta flash) if I run it again it won't find any guess my only mistake was testing out the beta

Yes! For an hour and had a hell of a time getting back

tower-diagnostics-20200822-1634.zip The odd thing is I can't even get a smart report from the drive I click start quick or extended and nothing happens. Drive is 15 months old wd SN750 Repurposed windows C:/ drive

Aug 22 14:35:10 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:10 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:12 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:12 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:13 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:13 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:33 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:33 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:37 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:37 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:41 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:41 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:42 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:42 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:44 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:35:44 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:36:01 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:36:01 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:36:03 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:36:03 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:36:12 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:36:12 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:36:13 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 Aug 22 14:36:13 Tower kernel: BTRFS critical (device nvme0n1p1): corrupt leaf: root=5 block=35338338304 slot=38 ino=181793 file_offset=1483358208, invalid offset for file extent, have 65535, should be aligned to 4096 What Should be my next step at this point

I don't believe I ever solved it it just went away with an Unraid update

Yep all "test" notifications work properly just not when it really counts! Lol, ok I'll try out the mirror syslog option to see what's going on thank you