newbie_dude

Oh I didn't even notice that. Thanks for the clarification!

Thank you!! Is there some test I can run to get greater confidence it's not the drive? Never had this error before and I've had the controller for years. Always appreciate your prompt help JB.

Just installed this not too long ago and some read errors reported. Got a diagnostics after it happened and put the system to sleep in case I needed to grab any other details that would be lost on a restart. Is the drive actually failing or could this be caused by another issue? Never had issues with my cabled. Any help would be greatly appreciated! tower-diagnostics-20200307-1219.zip

Hopefully this is the right spot for this question! I'm using an ASrock 970 Extreme3. When I use the S3 Sleep Plugin to put the system to sleep, the front LED blinks. According to The Manual blinking means S1 Sleep. PLED (System Power LED): LED is on when the system is operating. The LED keeps blinking when the system is in S1 sleep state. The LED is off when the system is in S3/S4 sleep state or powered off (S5). This seem to indicate the system is in S1 sleep and not S3. This would explain why I can't wake it up using etherwake -i eth0 xx:xx:xx:xx:xx:xx From my raspberry pi. Is there a way to verify what sleep state it's in? I have "Suspend to Ram: Auto" (manual page 50) Selected in BIOS. Or why my Wake on Lan isn't working? I do have "PCI Devices Power On"(manual page 50) enabled in the BIOS as well. Thank you! Below is an excerpt of the s3_sleep log. Not sure if it would shed any light: Jan 19 20:00:42 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:00:43 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:00:45 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:00:45 Tower s3_sleep: ---------------------------------------------- Jan 19 20:00:45 Tower s3_sleep: command-args=-C 1 -h 17 -h 18 -h 19 -h 20 -h 21 -h 22 -h 23 -m 30 -e eth0 -N 0 -D 0 Jan 19 20:00:45 Tower s3_sleep: action mode=sleep Jan 19 20:00:45 Tower s3_sleep: check disks status=no Jan 19 20:00:45 Tower s3_sleep: check network activity=no Jan 19 20:00:45 Tower s3_sleep: check active devices=no Jan 19 20:00:45 Tower s3_sleep: check local login=no Jan 19 20:00:45 Tower s3_sleep: check remote login=no Jan 19 20:00:45 Tower s3_sleep: version=3.0.6 Jan 19 20:00:45 Tower s3_sleep: ---------------------------------------------- Jan 19 20:00:45 Tower s3_sleep: included disks=sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl Jan 19 20:00:45 Tower s3_sleep: excluded disks=sda Jan 19 20:00:45 Tower s3_sleep: ---------------------------------------------- Jan 19 20:00:45 Tower s3_sleep: s3_sleep process ID 9973 started, To terminate it, type: s3_sleep -q Jan 19 20:00:46 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:00:47 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:00:48 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:02:17 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:02:18 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:02:19 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:02:21 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:02:21 Tower s3_sleep: ---------------------------------------------- Jan 19 20:02:21 Tower s3_sleep: command-args=-q Jan 19 20:02:21 Tower s3_sleep: action mode=sleep Jan 19 20:02:21 Tower s3_sleep: check disks status=no Jan 19 20:02:21 Tower s3_sleep: check network activity=no Jan 19 20:02:21 Tower s3_sleep: check active devices=no Jan 19 20:02:21 Tower s3_sleep: check local login=no Jan 19 20:02:21 Tower s3_sleep: check remote login=no Jan 19 20:02:21 Tower s3_sleep: version=3.0.6 Jan 19 20:02:21 Tower s3_sleep: ---------------------------------------------- Jan 19 20:02:21 Tower s3_sleep: included disks=sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl Jan 19 20:02:21 Tower s3_sleep: excluded disks=sda Jan 19 20:02:21 Tower s3_sleep: ---------------------------------------------- Jan 19 20:02:21 Tower s3_sleep: killing s3_sleep process 9973 Jan 19 20:02:22 Tower s3_sleep: ---------------------------------------------- Jan 19 20:02:22 Tower s3_sleep: command-args=-C 1 -h 17 -h 18 -h 19 -h 20 -h 21 -h 22 -h 23 -a -m 30 -n -e eth0 -N 0 -D 0 Jan 19 20:02:22 Tower s3_sleep: action mode=sleep Jan 19 20:02:22 Tower s3_sleep: check disks status=yes Jan 19 20:02:22 Tower s3_sleep: check network activity=yes Jan 19 20:02:22 Tower s3_sleep: check active devices=no Jan 19 20:02:22 Tower s3_sleep: check local login=no Jan 19 20:02:22 Tower s3_sleep: check remote login=no Jan 19 20:02:22 Tower s3_sleep: version=3.0.6 Jan 19 20:02:22 Tower s3_sleep: ---------------------------------------------- Jan 19 20:02:22 Tower s3_sleep: included disks=sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl Jan 19 20:02:22 Tower s3_sleep: excluded disks=sda Jan 19 20:02:22 Tower s3_sleep: ---------------------------------------------- Jan 19 20:02:22 Tower s3_sleep: s3_sleep process ID 10561 started, To terminate it, type: s3_sleep -q Jan 19 20:02:22 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:02:23 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:02:24 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:02:25 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Jan 19 20:23:25 Tower root: plugin: running: anonymous Jan 19 20:25:49 Tower kernel: i2c /dev entries driver Jan 19 20:27:28 Tower s3_sleep: ---------------------------------------------- Jan 19 20:27:28 Tower s3_sleep: command-args=-q Jan 19 20:27:28 Tower s3_sleep: action mode=sleep Jan 19 20:27:28 Tower s3_sleep: check disks status=no Jan 19 20:27:28 Tower s3_sleep: check network activity=no Jan 19 20:27:28 Tower s3_sleep: check active devices=no Jan 19 20:27:28 Tower s3_sleep: check local login=no Jan 19 20:27:28 Tower s3_sleep: check remote login=no Jan 19 20:27:28 Tower s3_sleep: version=3.0.6 Jan 19 20:27:28 Tower s3_sleep: ---------------------------------------------- Jan 19 20:27:28 Tower s3_sleep: included disks=sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl Jan 19 20:27:28 Tower s3_sleep: excluded disks=sda Jan 19 20:27:28 Tower s3_sleep: ---------------------------------------------- Jan 19 20:27:28 Tower s3_sleep: killing s3_sleep process 10561 Jan 19 20:27:28 Tower s3_sleep: ---------------------------------------------- Jan 19 20:27:28 Tower s3_sleep: command-args=-C 1 -h 17 -h 18 -h 19 -h 20 -h 21 -h 22 -h 23 -a -m 30 -n -e eth0 -N 62500 -D 0 Jan 19 20:27:28 Tower s3_sleep: action mode=sleep Jan 19 20:27:28 Tower s3_sleep: check disks status=yes Jan 19 20:27:28 Tower s3_sleep: check network activity=yes Jan 19 20:27:28 Tower s3_sleep: check active devices=no Jan 19 20:27:28 Tower s3_sleep: check local login=no Jan 19 20:27:28 Tower s3_sleep: check remote login=no Jan 19 20:27:28 Tower s3_sleep: version=3.0.6 Jan 19 20:27:28 Tower s3_sleep: ---------------------------------------------- Jan 19 20:27:28 Tower s3_sleep: included disks=sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl Jan 19 20:27:28 Tower s3_sleep: excluded disks=sda Jan 19 20:27:28 Tower s3_sleep: ---------------------------------------------- Jan 19 20:27:28 Tower s3_sleep: s3_sleep process ID 18608 started, To terminate it, type: s3_sleep -q Jan 19 20:37:19 Tower emhttpd: req (3): startState=STOPPED&file=&csrf_token=****************&cmdStart=Start Jan 19 20:37:21 Tower emhttpd: shcmd (2755): /usr/local/sbin/set_ncq sdb 1 Jan 19 20:37:21 Tower kernel: mdcmd (46): set md_num_stripes 1280

Hi, A drive that I just bought a few months ago is now disabled, and I'm not quite sure what happened. I've just recently run a parity check and it came back fine. I don't think there are any errors in the smart report (from what I understand). I've moved the sata connections around and it didn't seem to fix the issue. Before I switch more cables round or order a new drive, is there anything else I can do see if the drive is bad or it;s something else? Thank you! tower-smart-20200111-2318.zip tower-diagnostics-20200111-2316.zip

Thanks! Guess I have to do funky business to get my data off the drive and format.

Same "Cache drive unmountable: No pool uuid" issue when I tried to add a second cache disk. Original was formatted XFS. Error occurred when I started the array after choosing two slots and added the second drive. Now I notice the option to format as XFS is gone and only BTRFS is available. Also I can't change slots back to 1 and just go back to the old configuration. Is there a way to revert back? Does this mean I cannot have XFS formatted cache drives and must have BTRFS if I want cache protection? While googling I saw others had mentioned issues with BTRFS and recommended XFS. Looks like that's where my screwup was? tower-diagnostics-20200111-0937.zip

Thanks so much @johnnie.black Ran ddrescue and as per your post to move data onto a spare drive I had. Thankfully it seems as if I was able to recover most. I did a file system check and said all was good but I couldn't use it as a cache drive (file system error).. I don't know if I was doing something wrong or you can't just add a drive with some random data on it and call it a cache drive on unraid. Apologies if this sounds silly! Wanted to use the method to replace the cache drive as if it hadn't failed. So then I followed this video https://www.youtube.com/watch?v=ij8AOEF1pTU to put in a new ssd and copy the recovered data back onto the cache drive manually. The video had hints to get my dockers running again exactly as they were before. Next step would be to install the additional ssd and setup cache redundancy. Not sure if that was a good idea to not do that at the same time, but I didn't want to introduce too many variables at the same time. Thanks everyone for the help. Everyone here is the best!

Omg you're amazing. I'll plug in a new drive tonight and run ddrescue and reiserfsck. I'll keep fingers crossed. Thank you!

LOL Apologies. Should have posted diagnostics initially. tower-diagnostics-20200107-2226.zip

I ran the File system check and received the following output. Partially cropped. Looks as if the drive has actually gone bad and I would need to replace it. But in the mean time I did have data on the drive and would like to recover as much as I can. It was ~60% full (300GB capacity). Is there a way for me to recover the data on the drive onto another drive incase it fails mid recovery? I don't fully understand the suggestion below and would love an expert opinion on what my next steps should be. I've been putting off getting a couple of ssds to be redundant cache drives. I don't think I should have :( Thanks kindly for any help! reiserfsck 3.6.27 Will read-only check consistency of the filesystem on /dev/sdb1 Will put log info to 'stdout' ########### reiserfsck --check started at Tue Jan 7 20:25:34 2020 ########### Replaying journal: Trans replayed: mountid 254, transid 2230635, desc 1490, len 7, commit 1498, next trans offset 1481 Replaying journal: | | 0.2% 1 trans Trans replayed: mountid 254, transid 2230636, desc 1499, len 7, commit 1507, next trans offset 1490 ... ... ... Replaying journal: |====== \ 14.5% 91 trans Trans replayed: mountid 254, transid 2230726, desc 2654, len 7, commit 2662, next trans offset 2645 Trans replayed: mountid 254, transid 2230727, desc 2663, len 7, commit 2671, next trans offset 2654 Replaying journal: |====== | 14.8% 93 trans Trans replayed: mountid 254, transid 2230728, desc 2672, len 7, commit 2680, next trans offset 2663 Replaying journal: |====== / 14.9% 94 trans Trans replayed: mountid 254, transid 2230729, desc 2681, len 7, commit 2689, next trans offset 2672 The problem has occurred looks like a hardware problem. If you have bad blocks, we advise you to get a new hard drive, because once you get one bad block that the disk drive internals cannot hide from your sight,the chances of getting more are generally said to become much higher (precise statistics are unknown to us), and this disk drive is probably not expensive enough for you to you to risk your time and data on it. If you don't want to follow that follow that advice then if you have just a few bad blocks, try writing to the bad blocks and see if the drive remaps the bad blocks (that means it takes a block it has in reserve and allocates it for use for of that block number). If it cannot remap the block, use badblock option (-B) with reiserfs utils to handle this block correctly. bread: Cannot read the block (2688): (Input/output error).

I hoping I'm doing something stupid. My server configuration is attached. I use Viscosity in my mac for VPN. But I can't seem to connect to my unraid server It fails on TLS handshake. I've opened port 1194 in my router. Here is what I see on client side: Jan 08 14:32:22: Viscosity Mac 1.5.11 (1314) Jan 08 14:32:22: Viscosity OpenVPN Engine Started Jan 08 14:32:22: Running on Mac OS X 10.7.5 Jan 08 14:32:22: --------- Jan 08 14:32:22: Checking reachability status of connection... Jan 08 14:32:22: Connection is reachable. Starting connection attempt. Jan 08 14:32:22: OpenVPN 2.3.8 x86_64-apple-darwin [sSL (OpenSSL)] [LZO] [PKCS11] [MH] [iPv6] built on Sep 23 2015 Jan 08 14:32:22: library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09 Jan 08 14:32:23: Control Channel Authentication: using '/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/connection.puyVrx/ta.key' as a OpenVPN static key file Jan 08 14:32:23: UDPv4 link local: [undef] Jan 08 14:32:23: UDPv4 link remote: [AF_INET]99.XXX.XXX.XXX:1194 Jan 08 14:33:23: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Jan 08 14:33:23: TLS Error: TLS handshake failed Jan 08 14:33:23: SIGUSR1[soft,tls-error] received, process restarting Do I need to open more ports? Or is there something else with the configuration that's incorrect? Thanks for your help!

Same issue with osx. FTP is really fast. Going through AFP in finder is incredibly slow. I'll have to try the disable icon previews option . I wish there was a way to do that only for network shares. I like having the reviews for my local files

All you posted is the output of a smartctl report. It looks fine. What error are you seeing? Joe L. Oh. I thought the disk had errors. It was just listed on the final output. Things like Attribute NEW VAL OLD VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 118 101 6 OK 186259920 Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-end_error = 100 100 99 near_thresh 0 Airflow_Temper_Cel = 66 69 45 near_thresh 34 Temper_Cel = 34 31 0 ok 34 I was worried about the near_threshold issues. Does it sort of mean the disk is not new if there are old smart attribtes? Sorry, this is really confusing! It indicates the current normalized value is close to the affiliated failure threshold set by that disks manufacturer. Nobody knows how the "raw" counts on those attributes equate to the normalized values, at they typically do not tell, but if we assume the normalized value will decrement by 1 every time the disk fails to spin up, then it would take three failures to spin up to get to the affiliated failure threshold of 97. To me, even one failure to spin up is an issue, so if you ever see that value increasing, keep an eye on it. HOWEVER, the starting value for spin-retry is 100, and there have been NO failures in the raw column, so the disk has never failed to spin-up. (a good thing) The "near_thresh" is just there to help you decide if you need to investigate further. If you are that interested, you really should learn hoe to interpret the full smartctl reports, and not the summary the preclear script gives to you in its attempt to show you the parameters that have changed in the before and after reports. basically, according to what I can see from that difference report, the disk is fine. Joe L. Thanks so much! I'm going to start looking up to read the reports now. I have a feeling my cache drive is acting up from the reports in the unmenu section and I'd really like to know what it's saying. Once again, thanks!

All you posted is the output of a smartctl report. It looks fine. What error are you seeing? Joe L. Oh. I thought the disk had errors. It was just listed on the final output. Things like Attribute NEW VAL OLD VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 118 101 6 OK 186259920 Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-end_error = 100 100 99 near_thresh 0 Airflow_Temper_Cel = 66 69 45 near_thresh 34 Temper_Cel = 34 31 0 ok 34 I was worried about the near_threshold issues. Does it sort of mean the disk is not new if there are old smart attribtes? Sorry, this is really confusing!