1080p

Cheers Tom, the mvsas information you commented on sounds very similar to the issues I have been having so I will test this release as soon as possible and report my findings. Your work is very much appreciated in this corner

I'd prefer an SSHd come with unRAID and just be able to use sftp.

For those having issues with AFP & the CNID DB I was able to correct these following the instructions here: http://lime-technology.com/forum/index.php?topic=15657.0

Alrighty, I have run a couple of non-correcting parity checks with a new power supply. As far as I can tell this power supply is solid (has been running for ~12 months with no issues) and everything seems to be OK. I'll run it for a while longer to see if I run into any issues.

I bought the drives at different times and from a couple of dealers (whomever had the best deal at the time) so I hope it isn't the disks. I have another power supply that I'll be testing as soon as I can this weekend. Is there anything I can do to deliberately stress the power supply and potentially force an error like I have been seeing? I am not wanting to break stuff but I am also unsure about how to test a power supply.

Alright. I left the memory check running for a good while (40+ cycles) and all completed with no errors. Is anyone able to shed light on the errors in my syslogs and/or potential problems in my S.M.A.R.T. reports?

It hasn't been 12 hours but I haven't seen an error yet. If the RAM checks out, what should I test next?

Not a worry, I'll leave it for 12 hours and check on it tomorrow. Do I need to do anything to save a report it spits out or will it make it pretty obvious if I have memory issues?

Alright, I have powered down the server and will run memtest when I boot it again. How long should I run the tests for usually?

No. You mean a test like memtest or something, right?

Attached is a new syslog, it continues from my previous one at line 2342. Is this the parity sync completing? Mar 29 05:12:57 passionfruit kernel: md: sync done. time=38473sec Mar 29 05:12:57 passionfruit kernel: md: recovery thread sync completion status: 0 Note, I have increased my DHCP lease time to make the syslog a little more readable syslog-2012-03-29.zip

As an added note, none of my drives are redballed and I was able to complete a parity check last night. I see 160 errors in the errors column for my parity drive (sdb) & 64 errors on one of my data disks (sde) which have me worried. I have attached a screen grab for clarity.

S.M.A.R.T. reports are attached for all drives in use in the machine. /dev/sda is my cache drive. /dev/sdb is my parity drive. /dev/sdd - sdi are data drives. smart_reports.zip

unRAID Version: 5.0b11 Hardware: One of these filled with these (bought when they were a decent price ). Hi unRAID Community o/ I have been messing with unRAID a little for some time and had an odd error that occurs intermittently and I have had some difficulty nailing down what it is exactly. What I observe is a period of normal activity (reading, writing and parity checking) between a couple of days and a couple of weeks before I will encounter 'permissions errors' in a couple of apps which write to the server. I have learnt that permissions errors usually involve some problem with the filesystem so after I check the syslog (the attached syslog is typical for what happens) I run the reiserfsck tool on the affected drive and it will always tell me that --rebuild-tree is necessary. Running that will eventually (up to 48 hours later) end up with some kind of loop error that I do not recognise but it spectacularly fails and I am forced to halt the reiserfsck tool, reboot and completely pre-clear the drive and start again. This has happened on a number of different unRAID beta releases (including b8, b10, b11, b12a & b13) and each time I simply assumed it was an error with the beta I was using and have up/downgraded to test. b11 seems to be the most stable for me; I get ~1-2 weeks of uninterrupted usage. I am often lost when reading the syslog but to me it looks like some kind of RAID card error. Has anyone seen/experienced this error before? Just to be clear, my server contains two AOC-SASLP-MV8 cards. Many thanks for any assistance/insight offered and *ahem* ignore the dubious files my mover script is shifting. They are all legitimate Linux ISOs ;-) syslog-2012-03-28.zip

Just to confirm, I downgraded unRAID to 5.0b8 and was able to avoid the SATA card issues. I have two AOC-SASLP-MV8 cards installed which I assume was the cause of the bad behaviour. I was able to finish a parity sync and check so I am all protected. I upgraded my beta again to 5.0b10 (so Plex Media Server will work) and am re-running a parity sync and will run a check again to double check this beta is fine as well. Are the issues with the SATA cards documented anywhere else?

Cheers, I was using 5.0b13 in case anyone else has a similar issue.

Which version of 5.0b8+ should I try? I am using 3TB drives so I have to use b8+ right?

I am getting the feeling that one of my drive bays might be a little sketchy, I have removed the drive that I had in there and have begun a new attempt to gain parity. All was running well (it got to ~14%) and then I got this error: Jan 24 14:54:38 passionfruit kernel: sas: command 0xf0507900, task 0xf74663c0, timed out: BLK_EH_NOT_HANDLED I can see this is also asked in this thread but I would like to know more about this error and what I can do to work around it as I really want to make sure this server is protected as soon as possible.

Version 5.0b14 I am getting this exact error message while trying to generate a parity disk, it is freaking me out a little. Jan 24 14:54:38 passionfruit kernel: sas: command 0xf0507900, task 0xf74663c0, timed out: BLK_EH_NOT_HANDLED Are we able to see more information about the bug somewhere? Does it have a timetable for investigation? What can we do to work around it for now?

Attached is a copy & paste from the log of my management interface after starting the array & parity sync. I am running a short and long S.M.A.R.T. test as well. log.txt

Dix six is fine (as mentioned in the first post "One of the original drives (luckily it had no data on it) was red balled... the drive had had a power or data cable come loose.") it has since had a S.M.A.R.T. test come back fine. I have successfully removed the orange balled Disk 2 by stopping the array, unassigning Disk 2, powering down the array, removing Disk 2, powering on and typing initconfig. It worked this time. By the way, the Wiki does not mention this but when you refresh the management portal after typing initconfig all of the disks disappear from their assignments. I assume this is the desired behaviour but I would imagine you would want to warn users that they will need to take note of their old disk assignments. I think things could get hairy if you accidentally assign a data drive to the parity slot. I have begun another parity sync and it has, again, failed with the following error: Jan 24 10:22:37 passionfruit emhttp: mdcmd: write: Input/output error Jan 24 10:22:37 passionfruit kernel: mdcmd (299): spindown 0 Jan 24 10:22:37 passionfruit kernel: md: disk0: ATA_OP e0 ioctl error: -5 I have searched the forum here and got nothing close to an error like this. What is going on?

OK, I have attached the initial syslog. I have two unRAID addons (Simple Features & Plex MediaServer), should I disable them and attempt removing Disk 2 again? Forum does not allow .7z? Weird. syslog.zip

Any ideas on this? At the very least I'd love to be able to simply remove the drive and ensure I have a solid parity before doing anything else. I should also mention I am using one of the latter betas; 5.0b13 to be precise. I can attach the first 10,000 lines of syslog from before I started the initial parity check, I only captured that much as the log was enormous and at least three quarters of the file is the same error repeated.

Greetings unRAID community, I have recently had an issue with one of my servers that has me stumped. I generated the array and opted to wait on building a parity disk as I had a significant amount of data to write to the array first. After writing the data my last order of HDDs arrived and I added two more empty drives to expand the array further and another as my parity drive. After powering up the server again I started the initial parity calculation which appeared to go fine, I left the house as it took some time and when I returned there had been an error of some kind. One of the original drives (luckily it had no data on it) was red balled and the parity drive was orange balled and had (obviously) stopped calculating parity. I attempted a short S.M.A.R.T. test on the red ball drive which would not work (I was asked to add -T permissive options) so I figured that the drive had had a power or data cable come loose. I powered down the server, rechecked all the cabling and powered up again. The server started fine with the parity drive and Disk 2 orange but Disk 2 was also showing as Unformatted and I could only proceed with parity calculation if I first formatted the disk. As there had been no data stored on the disk I wend ahead with the format but the server did nothing and returned to its previous state. Confused I fired up my console (I wish unRAID shipped with SSH by default, installing unMenu just for SSH seems a little much) and checked to see if syslog could shed light. I saw a mention of what I thought could be the culprit: Jan 16 15:51:13 passionfruit emhttp: shcmd (337): set -o pipefail ; mkreiserfs -q /dev/md2 |& logger Jan 16 15:51:13 passionfruit logger: mkreiserfs 3.6.21 (2009 www.namesys.com) Jan 16 15:51:13 passionfruit logger: Jan 16 15:51:55 passionfruit emhttp: shcmd (338): mkdir /mnt/disk2 Jan 16 15:51:55 passionfruit emhttp: shcmd (339): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Jan 16 15:51:55 passionfruit kernel: REISERFS warning (device md2): sh-2021 reiserfs_fill_super: can not find reiserfs on md2 Jan 16 15:51:55 passionfruit logger: mount: wrong fs type, bad option, bad superblock on /dev/md2, Jan 16 15:51:55 passionfruit logger: missing codepage or helper program, or other error Jan 16 15:51:55 passionfruit logger: In some cases useful info is found in syslog - try Jan 16 15:51:55 passionfruit logger: dmesg | tail or so Jan 16 15:51:55 passionfruit logger: Jan 16 15:51:55 passionfruit emhttp: _shcmd: shcmd (339): exit status: 32 Jan 16 15:51:55 passionfruit emhttp: disk2 mount error: 32 Jan 16 15:51:55 passionfruit emhttp: shcmd (340): rmdir /mnt/disk2 Jan 16 15:51:56 passionfruit emhttp: shcmd (341): :>/etc/samba/smb-shares.conf Jan 16 15:51:56 passionfruit emhttp: shcmd (342): cp /etc/netatalk/AppleVolumes.default- /etc/netatalk/AppleVolumes.default Jan 16 15:51:56 passionfruit emhttp: Restart SMB... Jan 16 15:51:56 passionfruit emhttp: shcmd (343): killall -HUP smbd Jan 16 15:51:56 passionfruit emhttp: shcmd (344): ps axc | grep -q rpc.mountd Jan 16 15:51:56 passionfruit emhttp: _shcmd: shcmd (344): exit status: 1 Jan 16 15:51:56 passionfruit emhttp: Restart AFP... Jan 16 15:51:56 passionfruit emhttp: shcmd (345): killall -HUP afpd Jan 16 15:51:56 passionfruit emhttp: shcmd (346): cp /etc/avahi/services/afp.service- /etc/avahi/services/afp.service Jan 16 15:51:56 passionfruit avahi-daemon[7050]: Files changed, reloading. Jan 16 15:51:56 passionfruit avahi-daemon[7050]: Service group file /services/afp.service changed, reloading. Jan 16 15:51:56 passionfruit emhttp: shcmd (347): cp /etc/avahi/services/smb.service- /etc/avahi/services/smb.service Jan 16 15:51:56 passionfruit avahi-daemon[7050]: Files changed, reloading. Jan 16 15:51:56 passionfruit avahi-daemon[7050]: Service group file /services/smb.service changed, reloading. Jan 16 15:51:56 passionfruit emhttp: shcmd (348): /usr/local/sbin/emhttp_event svcs_restarted Jan 16 15:51:56 passionfruit emhttp_event: svcs_restarted This occurs after I click 'Format' from the management interface. What am I looking at here and what should I next try to troubleshoot? Another question, possibly related. I am a little nervous that I currently lack parity protection (data is still backed up elsewhere, just paranoid) so I tried to remove the drive (following the Wiki instructions) until I could learn more but was unsuccessful. My steps were stopping the array, removing the Disk 2 assignment and running initconfig from the console before starting the array again. This simply left the array with a red ball where Disk 2 was and would still not let me calculate parity. Have I done something wrong in trying to remove the disk?

Thanks for the reply Rajahal! It is good to know that I'll still be able to move files even if I want to seed them. I was considering using uTorrent's Scheduler to 'turn off' my torrents for +/- one hour each night and run the mover script just afterward if there were going to be major complications. My setup will be a little different to you. I like to keep torrents in certain folders (music in music/FLAC or music/MP3, Movies in film and so on...) and television is especially difficult to arrange. For this I have decided to use uTorrent's built in RSS manager which will allow me to save files in particular folders automatically. I will order a cache drive today and begin testing this next week