ny888

Since I got those IO errors on the syslog - the cache drive (sdb) has not been in the protected array and the system is stable. In the unRaid menu, it says sdb is unassigned but when I try to precelar it, I get this error message: Sorry: /dev/sdb does not exist as a block device Clearing will NOT be performed Not sure what I can do to get this drive back as a cache drive. It does not show up in /dev directory. Help !

In running this command - smartctl -a -d ata /dev/sda | todos >/boot/smart.txt I don't have an sdb in /dev ? Now I notice in unmenu that my sdb (cache) drive says RAW and has the NEW icon. It's been awhile since I installed this system. Do I do a preclear again?

I am running 5.0-rc8a. It's been very stable but the last couple of days, I come home to find the server unaccessible. Neither menu nor unmenu is reachable on the browser. In Finder on my Mac, I do not see the shares with aFP or SMB. Only thing I could do is force a reboot. After reboot, it seems ok, even parity check is fine but hours later, same thing happens again. I've attached full syslog from last reboot - many red errors. I see errors on sdb drive which is my cache drive. syslog-2013-12-03.txt

Deleting the Time Machine plist file finally worked although I had tried that before.

Thank you but not working for me. My wife's iMac has no problem with her Time Machine backups to the same share. Frustrating !

Time Machine has been working with my iMac for awhile, all of a sudden it can't see my unRaid server. I can get to all of my files just fine in the finder but the share doesn't show up as a backup disk in TM. I've tried a lot of things already. Any suggestions?

I have rsync daemon running on unRaid. Files are on /mnt/disk3/Backups/Snap - these files were originally sync'ed from a Windows Home Server using Robocopy. The WHS died so I replaced it with a Synology NAS, restored the entire Snap directory to it. I tried running this command to sync from Synology to unRaid: rsync -avs -h -i --dry-run --stats --progress --protect-args /volume1/Snap Maiko::mnt/disk3/Backups/Snap Using dry-run option I can see it is copying almost everything again to unRaid. If I telnet to unRaid from my Mac and do ls, I can see that the directories under Snap have spaces in the name (ie. /Snap/July\ Remodel), space between July and Remodel. Telneti and ls in the Synology NAS does not have the "\ ", instead just showing a space (ie. July Remodel). I'm guessing this is causing rsync to think all of the underlying folders are different. How do I fix this?

I did not have disk share turned on and turned it on - definitely improved response time in the Finder. Not great, but much better. Why is that? Meant to say performance in terms of drilling into folders is quicker accessing the dish share as opposed to the user share.

Since these backups are contained within just 1 disk, could it be a problem that I have split level set to 2 ? What hapens if I change the split level while the array is up?

I have been running unRaid since November of last year and it replaced 2 ReadyNAS NV+ systems. I have always had issues with one disk and I'm hoping someone can help me figure out why. All drives are WD 3TB Green drives. Parity (sda) Cache (sdb) Media share (sdc, sdd) - contains movies and shows under 4 different folders Backup share (sde) - contains Time Machine backups and backup of a Windows Home Server I am on a iMac running Mountain Lion. I started using cache_dirs because the Finder was always slow when trying to access Media or Backup. Since I started using cache_dirs, Media is very quick to respond when I click on it's folder or sub folders in Finder but Backup is still painfully slow to the point where sometimes all I get is the spinning ball and I have to relaunch Finder to get out of it. I can't undnerstand why that is, both shares are set up the same way. It doesn't matter whether I'm trying to access thru SMB or AFP. A week ago my switch failed and when I replaced it, my Windows Home Server would no longer start. Fortunately, the WHS was backed up every night using Robocopy to unRaid so I lost nothing. On my Backup share is a folder called Snap which is a duplicate of what I had on my WHS - all of our family photos, videos, documents, etc. Since I had the backup on the Backup share and it will take me awhile to replace the WHS with something else, I decide to copy the entire Snap folder on unRaid to my Thunderbolt drive on my iMac. At first I thought I'd just use Finder and copy the whole folder by Drag-n-Drop but it was painful seeing the Preparing to copy dialog that seemed to be taking forever. This was on 5/28. I killed that and instead went to do the copy in Terminal using this command - cp -Rv * /Volumes/"Thunderbolt Duo"/Snap This process started on 5/28 at 7:18pm. Since I used the -v option I could see that the process was again painfully slow. By the time I went to bed, very few folders and files had been copied. In the morning I checked and noticed it timed out all over the place on the morning of 5/29. Without doing anything, I decided to just issue the cp command again because I had to go on a business trip. This started on 5/29 at 5:50am and immediately I could see it was flying through the folders and files ! I've attached the syslog hoping someone can help me solve why this Backup disk has always given me trouble in Finder and why the same cp command at one time was slow and timed out and then worked as I had hoped after I had done nothing to change the environment. syslog-2013-05-31.txt.zip

Telnet'd into server from OSX terminal.

This is the exact command I'm using but I'm getting "Permission Denied" on all of the files. Logged on as root when I'm executing this.

I've searched the forums and found the commands and scripts to remove these files created by Mac but even logged on as root, I get Permission Denied. How do I fix this? What ls command option can I use to even see these files?

Ok, I've shutdown the system. re-seated the cables and started back up. The web interface is back. Will see if these errors pop up again. Thanks for the help.

The syslog is posted in the first post.