sureguy

Once you've logged in via putty/telnet just paste them, all at once should be fine, and hit enter.

As long as when telnet terminates you can still see your terminal session (Windows will ususally drop you back at a command prompt without being able to see what happened), you should be fine. If you are using Windows, you can still use the telnet protocol, but use a client like Putty (it's free and available here): http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty's default behaviour is to leave the window open if the connection is remotely closed.

Running the following from an ssh session works: flash=/dev/`ls -l /dev/disk/by-label| grep UNRAID | cut -d"/" -f3 | cut -c 1-3` # automatic id of flash drive while 1>2 do ((for d in $(ls /dev/[hs]d? | grep -v "$flash"); do hdparm -C $d | grep active ; done) | wc -l) sleep 60 done It'll run until you stop it or the server sleeps, checking the mount status of your drives every 60 seconds.

You could create a script that runs every minute with the following and output it to a file on your flash drive: for d in $(ls /dev/[hs]d? | grep -v "$flash"); do hdparm -C $d | grep active ; done) | wc -l I can't confirm this will work as I don't have access to my unRAID computer from work, but it's taken from your sleep script and appears to be the line checking to see if the drive is spun up or not. Then if it happens again, you'll know whether or not the drive was truly spun up. *EDIT* a better idea would probably to run the script from a ssh session (that doesn't automatically close its window if the connection is terminated).

Because of the way unRAID works it's always going to be slow at writing to disk (30MB/s is what I get). You can overcome this by using a cache drive and get faster write speeds (50-60MB/s), but a cache drive will eventually write to your array, and that will happen at 30MB/s. I suppose you could use all SSD drives, and that would be faster, but extremely expensive. I know at least on XBMC user was able to successfully stream 5 HD streams at once from unRAID. There are considerations in regards to your ability to do this. Ideally you would have a cache drive that moves files to your array drives when you wouldn't normally be streaming media (4am or whatever works for you). Also, unRAID is not a replacement for a proper backup. I don't consider backing up my commercial media as important as my personal media (family pictures, etc). The worst case scenario is I'd have to repurchase my media, I cannot recreate my personal media, so I have an offsite back up of things like that.

Is your computer connected directly to the router? If there's a switch in between try rebooting that as well.

I believe the last parity check being 15446 days ago is because you rebuilt the array. Even though it's the same disk, the array is considered new, and parity has never been checked. The same thing happens if you add another disk to the array, if I recall correctly.

Grab a flash drive, and copy the existing files from your flash drive to the new one, then run makebootable.bat on the new drive. You cannot backup your license (if you have one) as it's tied to the GUID of the flash drive. Hope that helps.

I use SSH keyfile based authentication to my router, and create a tunnel from there (also with SSH) to access my unRAID box. My router accepts SSH on a non-default port, and the keyfile I use is password protected. I feel pretty safe with this setup.

I had the same problem just this weekend. I'm at work right now so I can't provide the specifics of what I did, but here's an overview: I created a file in /boot/config called killoffenders - this stops my vm, and kills all the related services, and also kills Transmission, and makes sure a couple other things are no longer running (usenet/transmission/etc). The last thing it does is run umount -l /mnt/cache (forcing the cache drive to unmount lazily). All my usenet/vm/torrent services run from my cache drive and if something gets corrupt there I'm not too worried about it, I'd rather the machine shuts down safely when the power is out and deal with any cache issues later. I then opened the clean powerdown-1.02-noarch-unRAID.tgz file, added the line /boot/config/killoffenders to the file /sbin/powerdown after the line /etc/rc.d/rc.unRAID stop and saved the modified tgz. I'm still allowing the normal powerdown to be installed, and then I'm installing my modified one after, by adding a line to my /config/go file. I know I don't need to install both files. One caveat of this approach is that if you want to modify the configuration of the package you will need to modify the file you generated, or the modifications will be overwritten.

The WD20EARX is indeed an AF drive.

The only better thing I can think of is having the drive as a warm spare, but as you don't want to do that, preclearing the disk and ensuring you never touch it is the way to go. When a drive fails you want to replace it as soon as possible, and having a precleared disk goes a long way towards getting your system back up and running properly in a timely fashion.

In regards to worries about streaming recorded shows, and recording at the same time, you could add a cache drive so that the shows you're recording will be recorded to the cache drive, and the shows you're watching will be playing from a data drive. Then at 3am (or whenever you schedule) the recorded shows will be moved to the data drive.

You may not need a psu that can power everything. You can use a second PSU to power some of your disks and jumper the power connection so that it turns on. See http://www.overclock.net/t/96712/how-to-jump-start-a-power-supply-psu-test-a-power-supply-and-components

Is it possible your computer is trying to put the NIC/PC to sleep, thus disconnecting it from the network? I know this shouldn't happen, but I'd look at the power options for your NIC in device manager, and the power options for your computer in general.

Assuming none of your systems are running firewalls that block ping (ICMP) wait until the unRAID box loses network access and then try pinging the unRAID ip from another machine. If unRAID cannot ping anything but other things can ping the unRAID IP address you almost certainly have a conflict. You could also try running unRAID on 192.168.1.253 as that address is likely out of the DHCP scope of most routers, and probably not assigned to anything. Generally consumer modems/routers running DHCP give out address either at the lowest part of the block (192.168.1.1-192.168.1.100) or starting at 100 (192.168.1.100-192.168.1.200), at least from what I've seen.

Try a different port on your router or switch (the best would be the one your PC uses, as you know that one works properly). If you have the same issue there is something wrong with your NIC or the driver for it. Pick up an Intel gigabit NIC assuming you have a free slot on the motherboard.

Or you could set up ssh tunneling, and use a public/private keys rather than a password. Add a password to the keyfile and you're pretty safe.

The WNDR3700 should have gigabit ports. Ensure you're running a Cat 5e or Cat 6 cable to it.

There is some good information on buffers and cache here: http://www.linuxhowtos.org/System/Linux%20Memory%20Management.htm The main thing to be aware of in regards to buffers and cache is that linux will free up the memory when other processes need it.

Downloading the file works fine for me. Possibly just a hiccup from the boards being updated.

Are any of the drives in your MultiMedia share almost completely full?

Would it be possible to get a NOCORRECT option for the Scheduler parity check? I know it isn't likely there will be a problem, but I'd prefer to control whether or not the correction is done. Thanks a lot for the awesome work.

I downloaded cache_dirs from the first post in this thread, but when I run cache_dirs -V the version is listed as 1.6.5 - is this just a problem with the script misreporting the version number? *Edit* I just opened the script in an editor, it has notes about 1.6.6 and what was fixed, but the version variable is listed as 1.6.5 in the script.

I think this script is the issue. Part of the script copies the generated crontab file to /var/spool/cron/crontabs/root- Commenting out, or removing this part of the script should fix this issue.