tw332

Hi, So I’ve not done much to my array for years - it’s been happily serving away with no real issues. I recently decided it was overdue some maintenance and I noticed that one of the original disk drives was showing a Current Pending Sector reading of 1. So I decided to get a replacement disk and prepare to replace (it was my parity drive). I’ve replaced the drive that was showing the error. I’ve also used to opportunity to get the server up to date - current version of Unraid, added a couple of larger drives, upgraded file system of the existing drives to XFS… that kind of stuff. Now that I’ve finished the process, I’ve re-attached the issue drive to the array (excluded from user shares for now) and have completed a clear. Test reports that the Current Pending Sector count has returned to 0. Would the advice still be to get rid of the drive as it’s previously had an error or leave it in the array and see how it gets on? Thanks, Matt

I'm getting "Access Denied by server" errors when trying to browse Albums. I can browse genre and artist OK but Albums throws an error - any ideas? I'm also trying to set the server name using the "friendly_name" variable in the config file but the name still shows as MiniDLNA. Also tried setting as a container variable but again, no luck. Great work by the way. Another vote here for DSD support - hopefully a stable release becomes available soon!

Also running into the 2 account issue. Tried restarting/reinstalling a couple of times but no luck. I'm a long time unRAID user but new to v6 & Dockers... this was my first attempt at running a docker. Is there a way to rate or flag dockers as non-functional so they don't appear in the CA list?

Thanks - I'll get started on that.

For a moment I thought you were pointing me in the direction of obtaining historical logs! For anyone that's interested, I've performed SMART tests etc on the missing disk and have not been able to identify any issues. Server is operating as it always did. I've precleared the new disk and will be replacing the (non)missing disk with it soon. Would there be any preference to upgrading to the latest version before rebuilding on to the new disk or after. If it matters, I'm still on a v5 RC. Otherwise, the topic can be closed.

Hi, I've suffered issues with my server not responding on the web interface after a while of being online (sleeping daily and woken when needed). I can usually then log in via SSH and attempt a safe power down but that usually also freezes. (But that's a topic for another day.) At this point, unfortunately, it's a hard reset - which I had to do on Tuesday night. Server rebooted and at some point on Wednesday night, I noticed my shares were missing (presume the automatic parity check failed). Logging into the interface I noticed one of my disks was reported as missing... also noticed my email notifications weren't working! As I've not done any config with unRaid for a long time I completely forgot to save the log before rebooting. Rebooted - same issue. Did a quick bit of trouble shooting in the interface and in SSH and realised my mistake with the log. As I didn't have time to check cables and connections and as the drive was old and only placed in the server as a temporary measure (18 months ago, with the intention of replacing soon after)... I decided to order a new disk (which I've received today) and shut the server down to prevent any further risk. When I got home from work the next day, my server was woken automatically by magic packet. The server booted - disk was found and a parity check had been started. I cancelled the parity check and started a new one with the option to not write changes to the parity disk (I was unsure on the failed disk and wanted to see what unRaid would find without changing anything in parity). Zero errors were found - which is good. My question is (and apologies for the long winded post to get to it) - what's the best for me to do now? 1) pre-clear the new disk once and replace the older, possibly failing disk as soon as possible. 2) pre-clear the new disk several times with a view to replacing the older disk within the next month (and having it available in an emergency if the older disk does fail). 3) pre-clear the new disk and leave the older disk running until it fails. It's been quite a few years since I set up the server so apologies if any of this is outdated... (I am planning to upgrade to the newer versions sometime in the New Year). Thanks, Matt.

As I understand it, you cannot copy files from the parity disk as it is not formatted the same as the data disks. I think your only option is to rebuild the data disk based on the parity information you have. Then if you wish, replace the parity disk for one of the new ones you have. (You could aways mirror the parity disk onto the new precleared disk first - but then you'd only be adding another (unnecessary) step into the process, and would be using the exact same parity information.)

Hoping for some help - I'm trying to research an issue but my home internet is down and the works connection is heavily firewalled - so please accept my apologies if this has been discussed previously. I manually ran a routine "no correct" paritycheck from SF 1.0.11 (on RC11) overnight on Wednesday. On returning home, my syslog showed >1500 (or >15000, forgive my poor memory) parity errors but also showed a line stating "check CORRECT". Trying to debug, I ran another "no correct" parity check from SF. When the page refreshed, the status changed to show the check is in progress but with the "write corrections" box ticked. Checking the syslog again shows the "check CORRECT" line. The parity errors I received are a seperate issue (which I'll deal with in another post if I can't resolve) but I'm trying to confirm if the line in the syslog is confirming that the parity disk was updated to reflect the changes or if the check carried out was actually a "NOCORRECT". The results of the 2nd parity check returned 0 errors - so I'm unsure now whether parity was updated on the 1st check or if the errors showing were due to another issue. If the parity disk was updated, is there something else I need to do to carry out a "NOCORRECT" parity check - both times I am positive I unticked the box to request a "NOCORRECT".

If your'e trying to install the 3 packages listed, I would use the following lines in your Go script instead: installpkg /boot/packages/libelf-0.8.13-i486-2.txz installpkg /boot/packages/utempter-1.1.5-i486-1.txz installpkg /boot/packages/screen-4.0.3-i486-3.txz I personally installed Screen using unMenu though so I wouldn't know if the above would be all you need to install Screen.

I use Putty on the PC so can't confirm your exact steps but try : I use ConnectBot on Android to also connect to the unRAID box and had a similar error message to yours when attempting to re-attach to screen. If I remember, I changed the emulation mode to xterm.

You need to change your emulation options, which terminal client are you using?

BTW... The wiki post at http://lime-technology.com/wiki/index.php/Configuration_Tutorial#Preclearing_With_Screen should help

Just type "screen".. This will start a new session, where you can launch the preclear script. Once running, detach the screen session using Ctrl+A, Ctrl+D.

An explanation from Joe L would be nice. I believe he also wrote the cache dirs script, I assume he wants that removed as well? I still see the preclear package in the download. .... Sent from my SGH-T889 using Tapatalk 2 the plugin might still be avail, but the program download is no longer avail that the plugin looks for.... Myk I hope it wasn't because of any bugs or issues running preclear from SF as I'm currently clearing disks with it now. I personally have found this a great and easy way of running preclear and getting status updates.

I believe the standard for the new plugin architecture for unRAID 5 will have plugins at /boot/plugins and not /boot/config/plugins. Plus it keeps your config files seperate from plugins.

This is also noticable in the syslog when the array is not started - repeated messages in the syslog from emhttp and the kernal - this is known for 1.0.5 & 10.11 and also I believe the standard Webgui.

Not sure what I did wrong last night but had no issues upgrading today - all went fine. Like the new email notifications - I can now use my normal email account to send mail and no longer have to resort to using gmail. I'm also having an issue with the temp display : /boot/plugins# sensors -u k10temp-pci-00c3 Adapter: PCI adapter temp1: temp1_input: 14.125 temp1_max: 70.000 temp1_crit: 85.000 temp1_crit_hyst: 83.000 /boot/plugins# sensors k10temp-pci-00c3 Adapter: PCI adapter temp1: +14.1 C (high = +70.0 C) (crit = +85.0 C, hyst = +83.0 C) Dual-core AMD, MSI mobo (if it matters).

I realise this post is quite old but what skin are you using in the video? I feel like a change...

The red balled drive will be because of a write fail - looks like your issue started here: Feb 18 14:48:06 Tower init: Re-reading inittab Feb 18 14:48:13 Tower kernel: sas: command 0xc4370540, task 0xc41a2280, timed out: BLK_EH_NOT_HANDLED Feb 18 14:48:13 Tower kernel: sas: Enter sas_scsi_recover_host Feb 18 14:48:13 Tower kernel: sas: trying to find task 0xc41a2280 Feb 18 14:48:13 Tower kernel: sas: sas_scsi_find_task: aborting task 0xc41a2280 Feb 18 14:48:13 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1701:mvs_abort_task:rc= 5 Feb 18 14:48:13 Tower kernel: sas: sas_scsi_find_task: querying task 0xc41a2280 Feb 18 14:48:13 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1645:mvs_query_task:rc= 5 Feb 18 14:48:13 Tower kernel: sas: sas_scsi_find_task: task 0xc41a2280 failed to abort Feb 18 14:48:13 Tower kernel: sas: task 0xc41a2280 is not at LU: I_T recover Feb 18 14:48:13 Tower kernel: sas: I_T nexus reset for dev 0300000000000000 Feb 18 14:48:13 Tower kernel: sas: I_T 0300000000000000 recovered Feb 18 14:48:13 Tower kernel: sas: --- Exit sas_scsi_recover_host Feb 18 14:48:13 Tower kernel: ata2: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 Feb 18 14:48:13 Tower kernel: ata2: status=0x41 { DriveReady Error } Feb 18 14:48:13 Tower kernel: ata2: error=0x04 { DriveStatusError } Feb 18 14:48:13 Tower kernel: ata2: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 Feb 18 14:48:13 Tower kernel: ata2: status=0x41 { DriveReady Error } Feb 18 14:48:13 Tower kernel: ata2: error=0x04 { DriveStatusError } Feb 18 14:48:13 Tower kernel: ata2: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 Feb 18 14:48:13 Tower kernel: ata2: status=0x41 { DriveReady Error } Feb 18 14:48:13 Tower kernel: ata2: error=0x04 { DriveStatusError } Feb 18 14:48:13 Tower kernel: ata2: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00 Feb 18 14:48:13 Tower kernel: ata2: status=0x41 { DriveReady Error } Feb 18 14:48:13 Tower kernel: ata2: error=0x04 { DriveStatusError } Feb 18 14:48:13 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md11, Feb 18 14:48:13 Tower logger: missing codepage or helper program, or other error Feb 18 14:48:13 Tower logger: In some cases useful info is found in syslog - try Feb 18 14:48:13 Tower logger: dmesg | tail or so Feb 18 14:48:13 Tower logger: Feb 18 14:48:13 Tower emhttp: _shcmd: shcmd (41): exit status: 32 Feb 18 14:48:13 Tower emhttp: disk11 mount error: 32 Feb 18 14:48:13 Tower emhttp: shcmd (42): rmdir /mnt/disk11 But that all relates to disk 11 - as does : Feb 18 14:48:13 Tower kernel: sd 1:0:1:0: [sdc] Result: hostbyte=0x00 driverbyte=0x08 Feb 18 14:48:13 Tower kernel: sd 1:0:1:0: [sdc] Sense Key : 0xb [current] [descriptor] Feb 18 14:48:13 Tower kernel: Descriptor sense data with sense descriptors (in hex): Feb 18 14:48:13 Tower kernel: 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 Feb 18 14:48:13 Tower kernel: 00 00 00 c6 Feb 18 14:48:13 Tower kernel: sd 1:0:1:0: [sdc] ASC=0x0 ASCQ=0x0 Feb 18 14:48:13 Tower kernel: sd 1:0:1:0: [sdc] CDB: cdb[0]=0x28: 28 00 b3 1a 43 c7 00 00 08 00 Feb 18 14:48:13 Tower kernel: end_request: I/O error, dev sdc, sector 3004842951 Feb 18 14:48:13 Tower kernel: md: disk11 read error Couldn't see anything relating to disk 10 - maybe that was before the start of this log? (You do say "one day, i noticed.) I'd say the obvious culprit would have been the controller. Unfortunately, I can't offer any more advice - hopefully someone more technically able will reply.

I'll have to give the new version another go tomorrow. Installed as per the instructions (removed the existing version 1st). Not sure what I did wrong but the page then refused to display correctly at all, also lost SSH access (and other packages installed via unMENU - not sure how that's happened!) Tried for hours to get everything up and running again. Luckily I'd backed up my flash drive earlier so I've reverted to that - all now back as it was. I'll give ver 1.0.11 another go tomorrow - possibly from a completely fresh install of unRAID.

I also have this issue. After the system has gone to sleep twice. When waking for the second time, I find the webgui does not respond. Usually unMenu still works but on this occasion (tonight) - unMenu also did not respond.

I'm currently running without a parity drive but noticed that when the server wakes from sleep the array is automatically started. This doesn't happen on a fresh boot. I presume the sleep/wake up script is starting the array but can't find any reference to it in settings/logs.

Snap - having the same issue here - RC11 and 1.05.

I've experinced very slow transfers (similar to yours) from my laptop to my unRAID box and established the issue (in my case) was my router. If I take the router out of the equation, speeds increase dramatically. Which is why I've added a new Gigabit switch/router to my shopping list for some time in the (hopefully, not too distant) future.

I also, if it were my server, would like to get to the bottom of the issue and would rather find out what's wrong than leave it with the possibility of the of future problems. In my opinion, with the errors above, it looks like the drive is having difficulty reading part of the data. However, without knowing how the values are changing (eg the rate they're increasing, if they are in fact increasing) it would be difficult to determine if that's a drive issue, interface issue or something else entirely. Again, hopefully one of the more experienced members can comment.