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?