devanchya

You sent me down a rabbit hole. Looks like it would take a month for a card to get to me. Anything I can do for safety now? Doesn't seem that anyone in Toronto sells these off the shelf anymore...

I haven't used LSI SAS to Sata before, anything I need to know. A manual or read-up will do.

@johnnie.black can you suggest a replacement. I got these from someone else recommending them and obviously lost the bet.

thanks @itimpi , I have replaced all the SATA cables already, and moved to a different port as well.

I've attached the diagnostics. I haven't found anything obvious in them, but obviously I wouldn't be here if I could see it tower-diagnostics-20190802-1415.zip

I've been having issues with my unraid and I can't track down the cause of it. The ATA is being dropped with a hard reset, and coming back up at a lower level. These are 6 Gbps connections, and the first drop go down to 3 Gbps and then later 1.5 Gbps. I've changed sata cables, power supply, SATA controllers, motherboard, even different drives and this keeps occuring. I'm at a loss what could be causing this. It occurs during rebuilding of Parity and Plex streaming. I'm out of ideas what could be causing it. Any suggestions GREATLY appreciated. Aug 2 05:03:38 Tower kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Aug 2 05:03:38 Tower kernel: ata7.00: failed command: WRITE DMA EXT Aug 2 05:03:38 Tower kernel: ata7.00: cmd 35/00:08:88:ce:3f/00:00:7f:00:00/e0 tag 12 dma 4096 out Aug 2 05:03:38 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Aug 2 05:03:38 Tower kernel: ata7.00: status: { DRDY } Aug 2 05:03:38 Tower kernel: ata7: hard resetting link Aug 2 05:03:39 Tower kernel: ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Aug 2 05:03:39 Tower kernel: ata7.00: configured for UDMA/33 Aug 2 05:03:39 Tower kernel: ata7: EH complete

Thank you it was Disk 2 that was damaged in the XFS. It's a new drive so I'm doing extra checks on it.

I'm having an issue where MOVER is making my /mnt/user*/ go read only. It appears to be due to a Metadata CRC error, but I can't tell where. There is no log saying which drive this is occurring on. All my drives appear GREEN in UnRaid. All Smart data looks good. I'm stumped. Jun 13 11:40:14 Tower kernel: XFS (md2): Metadata CRC error detected at xfs_allocbt_read_verify+0xd/0x3a [xfs], xfs_allocbt block 0x3a382228 Jun 13 11:40:14 Tower kernel: XFS (md2): Unmount and run xfs_repair Jun 13 11:40:14 Tower kernel: XFS (md2): First 128 bytes of corrupted metadata buffer: Jun 13 11:40:14 Tower kernel: 000000000dbd6522: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000eedb3762: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000d06bd14d: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000dae76d5c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000cf714964: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 000000001f761a42: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 00000000ba3c7088: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: 0000000068f2624d: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jun 13 11:40:14 Tower kernel: XFS (md2): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x3a382228 len 8 error 74

When I check /mnt/cache it shows 600gb in my one directory that should have been moved to other drives however when I run /usr/local/sbin/mover it immediately states it is finished running. This is for 6.2 RC4 Logs show no text output other than "mover finished" The "Cache" option had been turned off. Fixing the settings in the share worked

thanks john. Its worth a shot.

One of the ports on my main machine appears to have gone bad. It's a long story but the ESata would connect to the 4 drive bay properly, but after about 15 minutes the drives would spin down and I could not spin them back up. Added to the join I discovered this issue halfway through a parity check which stopped at 33% ... so my Parity drive may be full of bad data. I've replaced the cable, same issue. Tried another cable and it wouldn't even see the enclosure. Tried another enclosure, same issue as first enclosure. I decided to see if USB worked, and being UNRAID I was sure it wouldn't... and was surprised that Unraid 6.2RC appears to support USB (I've been around a long time, so forgive me for missing this... 4.7 days) However USB changed the ID of the drives by adding some USB Specific code to the drive Serial name. I've manually mounted the drives and confirmed they are in the proper spots. It helped they were 2TB, 3TB, and 4TB so could tell by size as well. However I'm stuck with the To many missing or incorrect disks cfg error. Is there anyway to fix this so I can try to see if Partiy will restore (did I forget to mention?) the one drive that had died.

I currently have a large set of data of similar types. TV Shows etc. Some of the shows are split across 20+ drives. I would like to consolidate some of the data to same drives prior to migrating the drives to larger capacity. Is there any way to automatically get all of X show to Drive 3 for example.

The drives were mis-labeled for type, and it appears a a single ext-sata cord was loose from some long term vibration.

attaching diagnostics tower-diagnostics-20160712-0609.zip

6.1.9, unraid. I have 10 drives showing mountable, 10 drives suddenly showing not mountable. I had 1 drive show up bad yesterday so I rebooted the box to check if it was a false positive until I could get a replacement. Machine came up. BIOS missing, had to rebuild using backup bios. UnRaid comes up, all the drive configurations are missing. I bring up the drives (with no parity) and confirm that 10 are working properly, the other 10 are showing unmountable Whats the best way to confirm the other drives are still good? I was thinking of manually mounting them in /mnt temporarly. I'm still trying to figure out a cause. the 10 drives that are down may be connected via an external SATA card so it could be a case of the BIOS not loading the card right after a reset, still checking. Jul 11 19:42:14 Tower kernel: REISERFS warning (device md1): sh-2011 read_super_block: can't find a reiserfs filesystem on (dev md1, block 16, size 4096) Jul 11 19:42:14 Tower kernel: REISERFS warning (device md1): sh-2021 reiserfs_fill_super: can not find reiserfs on md1 Jul 11 19:42:14 Tower emhttp: shcmd: shcmd (48): exit status: 32 Jul 11 19:42:14 Tower emhttp: mount error: No file system (32) Jul 11 19:42:14 Tower emhttp: shcmd (49): rmdir /mnt/disk1 Jul 11 19:42:14 Tower emhttp: shcmd (50): mkdir -p /mnt/disk2 Jul 11 19:42:14 Tower emhttp: shcmd (51): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Jul 11 19:42:14 Tower kernel: REISERFS (device md2): found reiserfs format "3.6" with standard journal Jul 11 19:42:14 Tower kernel: REISERFS (device md2): using ordered data mode Jul 11 19:42:14 Tower kernel: reiserfs: using flush barriers Jul 11 19:42:14 Tower kernel: REISERFS (device md2): journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jul 11 19:42:14 Tower kernel: REISERFS (device md2): checking transaction log (md2) Jul 11 19:42:14 Tower kernel: REISERFS (device md2): Using r5 hash to sort names Jul 11 19:42:15 Tower emhttp: shcmd (52): set -o pipefail ; mount -t reiserfs -o remount,user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Jul 11 19:42:15 Tower emhttp: reiserfs: resizing /mnt/disk2 Jul 11 19:42:15 Tower emhttp: shcmd (53): mkdir -p /mnt/disk3 Jul 11 19:42:15 Tower emhttp: shcmd (54): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Jul 11 19:42:15 Tower kernel: REISERFS (device md3): found reiserfs format "3.6" with standard journal Jul 11 19:42:15 Tower kernel: REISERFS (device md3): using ordered data mode Jul 11 19:42:15 Tower kernel: reiserfs: using flush barriers Jul 11 19:42:15 Tower kernel: REISERFS (device md3): journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jul 11 19:42:15 Tower kernel: REISERFS (device md3): checking transaction log (md3) Jul 11 19:42:15 Tower kernel: REISERFS (device md3): Using r5 hash to sort names Jul 11 19:42:15 Tower emhttp: shcmd (55): set -o pipefail ; mount -t reiserfs -o remount,user_xattr,acl,noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Jul 11 19:42:15 Tower emhttp: reiserfs: resizing /mnt/disk3 Jul 11 19:42:15 Tower emhttp: shcmd (56): mkdir -p /mnt/disk4 Jul 11 19:42:15 Tower emhttp: shcmd (57): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md4 /mnt/disk4 |& logger Jul 11 19:42:15 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md4, Jul 11 19:42:15 Tower logger: missing codepage or helper program, or other error Jul 11 19:42:15 Tower logger: In some cases useful info is found in syslog - try Jul 11 19:42:15 Tower logger: dmesg | tail or so Jul 11 19:42:15 Tower logger: Jul 11 19:42:15 Tower emhttp: shcmd: shcmd (57): exit status: 32 Jul 11 19:42:15 Tower emhttp: mount error: No file system (32) Jul 11 19:42:15 Tower emhttp: shcmd (58): rmdir /mnt/disk4 Jul 11 19:42:15 Tower kernel: REISERFS warning (device md4): sh-2021 reiserfs_fill_super: can not find reiserfs on md4 Jul 11 19:42:15 Tower emhttp: shcmd (59): mkdir -p /mnt/disk5 Jul 11 19:42:15 Tower emhttp: shcmd (60): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md5 /mnt/disk5 |& logger Jul 11 19:42:15 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md5, Jul 11 19:42:15 Tower logger: missing codepage or helper program, or other error Jul 11 19:42:15 Tower logger: In some cases useful info is found in syslog - try Jul 11 19:42:15 Tower logger: dmesg | tail or so

I seem to be getting a larger loss of files than I expected. The old world of UnRaid had an issue with duplicate files that could occur? is that still the case? Is there any plug-ins or other services that can show me the largest files / directories for my TV / Movie collection to see where my space may be evaporating to?

figured it out. Don't start up a disk array with parity installed while testing this. Disk 0 was Parity. Disk 1 through 19 where Disk 1 through 19, and the cache was the final disk.

My flash drive died last night after Years of good service. The famous bzboot boot bug that I see on some corruption pages. Now my issue is, the drive is good enough to read from... but I don't know how to restore my drive listing. The screen shot I have is missing a few drives, forgot to update it. I have the syslog from a (few) months and I can see drive0 to drive 19. which is the parity drive? Jun 8 18:00:58 Tower kernel: mdcmd (1): import 0 65,0 3907018532 WDC_WD40EFRX-68WT0N0_WD-WCC4E0462986 Jun 8 18:00:58 Tower kernel: md: import disk0: [65,0] (sdq) WDC_WD40EFRX-68WT0N0_WD-WCC4E0462986 size: 3907018532 Jun 8 18:00:58 Tower kernel: mdcmd (2): import 1 8,160 2930266532 WDC_WD30EFRX-68AX9N0_WD-WCC1T0400445 Jun 8 18:00:58 Tower kernel: md: import disk1: [8,160] (sdk) WDC_WD30EFRX-68AX9N0_WD-WCC1T0400445 size: 2930266532 Jun 8 18:00:58 Tower kernel: mdcmd (3): import 2 65,16 2930266532 WDC_WD30EFRX-68AX9N0_WD-WCC1T0403468 Jun 8 18:00:58 Tower kernel: md: import disk2: [65,16] (sdr) WDC_WD30EFRX-68AX9N0_WD-WCC1T0403468 size: 2930266532 Jun 8 18:00:58 Tower kernel: mdcmd (4): import 3 65,32 3907018532 WDC_WD40EFRX-68WT0N0_WD-WCC4E0755641 Jun 8 18:00:58 Tower kernel: md: import disk3: [65,32] (sds) WDC_WD40EFRX-68WT0N0_WD-WCC4E0755641 size: 3907018532 Jun 8 18:00:59 Tower kernel: mdcmd (5): import 4 65,64 1953514552 WDC_WD20EARS-00MVWB0_WD-WMAZA3697899 Jun 8 18:00:59 Tower kernel: md: import disk4: [65,64] (sdu) WDC_WD20EARS-00MVWB0_WD-WMAZA3697899 size: 1953514552 Jun 8 18:00:59 Tower kernel: mdcmd (6): import 5 65,80 1953514552 WDC_WD20EARS-00MVWB0_WD-WMAZA4502352 Jun 8 18:00:59 Tower kernel: md: import disk5: [65,80] (sdv) WDC_WD20EARS-00MVWB0_WD-WMAZA4502352 size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (7): import 6 8,16 1953514552 WDC_WD20EARS-00MVWB0_WD-WMAZA4503900 Jun 8 18:01:00 Tower kernel: md: import disk6: [8,16] (sdb) WDC_WD20EARS-00MVWB0_WD-WMAZA4503900 size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (: import 7 8,32 1953514552 ST2000DL003-9VT166_5YD5VB7A Jun 8 18:01:00 Tower kernel: md: import disk7: [8,32] (sdc) ST2000DL003-9VT166_5YD5VB7A size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (9): import 8 8,48 1953514552 WDC_WD2002FAEX-007BA0_WD-WMAWP0250684 Jun 8 18:01:00 Tower kernel: md: import disk8: [8,48] (sdd) WDC_WD2002FAEX-007BA0_WD-WMAWP0250684 size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (10): import 9 8,96 3907018532 WDC_WD40EFRX-68WT0N0_WD-WCC4EE7P27CY Jun 8 18:01:00 Tower kernel: md: import disk9: [8,96] (sdg) WDC_WD40EFRX-68WT0N0_WD-WCC4EE7P27CY size: 3907018532 Jun 8 18:01:00 Tower kernel: mdcmd (11): import 10 8,64 1953514552 WDC_WD20EFRX-68AX9N0_WD-WMC300547428 Jun 8 18:01:00 Tower kernel: md: import disk10: [8,64] (sde) WDC_WD20EFRX-68AX9N0_WD-WMC300547428 size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (12): import 11 8,80 1953514552 WDC_WD20EFRX-68AX9N0_WD-WMC300260636 Jun 8 18:01:00 Tower kernel: md: import disk11: [8,80] (sdf) WDC_WD20EFRX-68AX9N0_WD-WMC300260636 size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (13): import 12 8,112 3907018532 WDC_WD40EFRX-68WT0N0_WD-WCC4EFAKRAHC Jun 8 18:01:00 Tower kernel: md: import disk12: [8,112] (sdh) WDC_WD40EFRX-68WT0N0_WD-WCC4EFAKRAHC size: 3907018532 Jun 8 18:01:00 Tower kernel: mdcmd (14): import 13 8,128 1953514552 ST32000542AS_5XW1CAKX Jun 8 18:01:00 Tower kernel: md: import disk13: [8,128] (sdi) ST32000542AS_5XW1CAKX size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (15): import 14 8,176 1953514552 WDC_WD20EFRX-68AX9N0_WD-WMC302116130 Jun 8 18:01:00 Tower kernel: md: import disk14: [8,176] (sdl) WDC_WD20EFRX-68AX9N0_WD-WMC302116130 size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (16): import 15 8,192 3907018532 WDC_WD40EFRX-68WT0N0_WD-WCC4E0758643 Jun 8 18:01:00 Tower kernel: md: import disk15: [8,192] (sdm) WDC_WD40EFRX-68WT0N0_WD-WCC4E0758643 size: 3907018532 Jun 8 18:01:00 Tower kernel: mdcmd (17): import 16 8,208 1953514552 WDC_WD20EARX-00MMMB0_WD-WMAWZ0294551 Jun 8 18:01:00 Tower kernel: md: import disk16: [8,208] (sdn) WDC_WD20EARX-00MMMB0_WD-WMAWZ0294551 size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (18): import 17 8,224 1953514552 ST32000542AS_5XW198DK Jun 8 18:01:00 Tower kernel: md: import disk17: [8,224] (sdo) ST32000542AS_5XW198DK size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (19): import 18 8,240 1953514552 WDC_WD20EARS-00MVWB0_WD-WMAZA3740284 Jun 8 18:01:00 Tower kernel: md: import disk18: [8,240] (sdp) WDC_WD20EARS-00MVWB0_WD-WMAZA3740284 size: 1953514552 Jun 8 18:01:00 Tower kernel: mdcmd (20): import 19 65,48 1953514552 WDC_WD20EARS-00MVWB0_WD-WMAZA0796451 Jun 8 18:01:00 Tower kernel: md: import disk19: [65,48] (sdt) WDC_WD20EARS-00MVWB0_WD-WMAZA0796451 size: 1953514552 Jun 8 18:01:00 Tower emhttp: import 20 cache device: sdj Jun 8 18:01:00 Tower emhttp: import flash device: sda [code]

https://github.com/evilhero/mylar I feel a bit dirty requesting it... but anyone know of a Docker with Mylar that works? I'm trying to finalize the "perfect machine".

Can we get an option to force a docker to run in -u nobody. The Media Browser service can be installed by command line by running -u but appears to fail in the configuration web option due to not running in -u mode.

Inside NZBdrone you reference to the path as /tv not as /mnt... Was that your issue?

And today I learned how to use the new extension with out a template, and feel so stupid for not realizing it beforehand.

there is no template for the extension for nzbdrone though

NZBDrone had an update a few days ago: 2.0.0.1690 - July 23 2014 needo/nzbdrone was last built on the 23rd: bsdjewnvrhcijwdgbqcgqca Finished 2014-07-23 23:17:35 2014-07-23 23:25:11 but doesn't appear to have this update. am I not updating the image correctly by doing a docker pull needo/nzbdrone then stoping and starting the image? (docker stop nzbdrone, docker start nzbdrone)

You can't update from inside since it is a read-only OS and the update script assumes it has write access (yes I tried that). The Dev branch runs off the GIT develop branch. I'm not sure of they have an apt development branch...