April 9, 200917 yr A few months ago I set up my unraid server using 4.3. It worked fine for about a month. Then I had to move to a new apartment and it was disconnected for a few months. When I started it back up, I deleted the data on the server (I did not touch the data on the flash card) to back up new stuff and all of a sudden now it won't work. It says: "Can't copy XXXXX: The specified "path or something" is no longer available." I haven't changed anything. All the same components and everything (cables, router, etc.) are the same. So I thought maybe an update would fix it so I updated to 4.4 and I still have the same problem. Halfway though copying a file to the server I get that message. I looked at other threads that say the same thing, but I don't see a solution. I updated to 4.4 and it is still happening.
April 9, 200917 yr A few months ago I set up my unraid server using 4.3. It worked fine for about a month. Then I had to move to a new apartment and it was disconnected for a few months. When I started it back up, I deleted the data on the server (I did not touch the data on the flash card) to back up new stuff and all of a sudden now it won't work. It says: "Can't copy XXXXX: The specified "path or something" is no longer available." I haven't changed anything. All the same components and everything (cables, router, etc.) are the same. So I thought maybe an update would fix it so I updated to 4.4 and I still have the same problem. Halfway though copying a file to the server I get that message. I looked at other threads that say the same thing, but I don't see a solution. I updated to 4.4 and it is still happening. Highest probability is that one of your LAN cables is either not fully plugged in, or defective, and that communications between the PC and unRAID server is not reliable. First step, try different LAN cables... especially if you made them yourself, but even if you purchased them from a computer store. Since you moved the server, you might want to open it up and make sure all the interface cards in it are seated properly in their sockets. A loose card would cause all kinds of errors... (but you would likely see them in the syslog) It does not have to be an issue with the unRAID server, it could as easily be the PC... For it to say the connection to the server is no longer available it must think the network connection is un-available. Did you look in the system log? Does it offer any clues? Does an ifconfig eth0 show you any errors? How did you "delete" the data on the server? Did you do it from the PC? Post a copy of your syslog if you wish assistance in interpreting its contents. Joe L.
April 10, 200917 yr Author Well I have been using these cables with my PC and xbox with no problem, I just reformatted my pc to make sure it wasn't a problem with that (it was time for a clean up anyways). I have the system log but it is huge! Without looking at the syslog the problem appears to be with the unradi server itself. It will stop copy data and then become unresponsive. Anyways how do I post the syslog, the forum says it is too many characters. These are the last few lines of the log. I have no idea how to make sense of this stuff. Apr 9 15:22:29 Tower ifplugd(eth0)[1005]: client: dhcpcd: MAC address = 00:1f:d0:97:74:bc Apr 9 15:22:29 Tower ifplugd(eth0)[1005]: client: dhcpcd: your IP address = 192.168.1.101 Apr 9 15:22:29 Tower ifplugd(eth0)[1005]: client: dhcpcd: MAC address = 00:1f:d0:97:74:bc Apr 9 15:22:29 Tower ifplugd(eth0)[1005]: client: dhcpcd: your IP address = 192.168.1.101 Apr 9 15:22:29 Tower ifplugd(eth0)[1005]: Program executed successfully. Apr 9 15:22:29 Tower rpc.statd[1048]: Version 1.1.4 Starting Apr 9 15:22:29 Tower emhttp: unRAID System Management Utility version 4.4.2 Apr 9 15:22:29 Tower emhttp: Copyright © 2005-2008, Lime Technology, LLC Apr 9 15:22:29 Tower emhttp: Unregistered Apr 9 15:22:29 Tower emhttp: shcmd (1): mkdir -m 700 /boot/config/shares Apr 9 15:22:29 Tower emhttp: Device inventory: Apr 9 15:22:29 Tower emhttp: pci-0000:00:11.0-scsi-2:0:0:0 (sda) ata-WDC_WD10EACS-00D6B1_WD-WCAU44179194 Apr 9 15:22:29 Tower emhttp: shcmd (2): rmmod md-mod >>/var/log/go 2>&1 Apr 9 15:22:29 Tower emhttp: shcmd: shcmd (2): exit status: 1 Apr 9 15:22:29 Tower emhttp: shcmd (3): modprobe md-mod super=/boot/config/super.dat slots=0,0,0,0,0,0 >>/var/log/go 2>&1 Apr 9 15:22:29 Tower kernel: md: unRAID driver 0.95.0 installed Apr 9 15:22:29 Tower kernel: md: xor using function: p5_mmx (6909.200 MB/sec) Apr 9 15:22:29 Tower kernel: read_file: error 2 opening /boot/config/super.dat Apr 9 15:22:29 Tower kernel: md: could not read superblock from /boot/config/super.dat Apr 9 15:22:29 Tower kernel: md: initializing superblock Apr 9 15:22:29 Tower emhttp: shcmd (4): /etc/rc.d/rc.samba stop >/dev/null Apr 9 15:22:29 Tower emhttp: shcmd (5): /etc/rc.d/rc.nfsd stop >/dev/null Apr 9 15:22:30 Tower emhttp: shcmd (6): cp /etc/exports- /etc/exports Apr 9 15:22:30 Tower emhttp: shcmd (7): /etc/rc.d/rc.samba start >/dev/null Apr 9 15:22:30 Tower emhttp: shcmd (: /etc/rc.d/rc.nfsd start >/dev/null Apr 9 15:23:03 Tower emhttp: shcmd (9): rmmod md-mod >>/var/log/go 2>&1 Apr 9 15:23:03 Tower kernel: md: unRAID driver removed Apr 9 15:23:03 Tower emhttp: shcmd (10): modprobe md-mod super=/boot/config/super.dat slots=0,0,8,0,0,0 >>/var/log/go 2>&1 Apr 9 15:23:03 Tower kernel: md: unRAID driver 0.95.0 installed Apr 9 15:23:03 Tower kernel: md: xor using function: p5_mmx (6909.200 MB/sec) Apr 9 15:23:03 Tower kernel: read_file: error 2 opening /boot/config/super.dat Apr 9 15:23:03 Tower kernel: md: could not read superblock from /boot/config/super.dat Apr 9 15:23:03 Tower kernel: md: initializing superblock Apr 9 15:23:03 Tower kernel: md: import disk1: [8,0] (sda) WDC WD10EACS-00D6B1 WD-WCAU44179194 offset: 63 size: 976761496 Apr 9 15:23:03 Tower kernel: md: disk1 new disk Apr 9 15:23:03 Tower kernel: md: import disk1: [8,0] (sda) WDC WD10EACS-00D6B1 WD-WCAU44179194 offset: 63 size: 976761496 Apr 9 15:23:03 Tower kernel: md: disk1 new disk Apr 9 15:23:05 Tower kernel: md: import disk1: [8,0] (sda) WDC WD10EACS-00D6B1 WD-WCAU44179194 offset: 63 size: 976761496 Apr 9 15:23:05 Tower kernel: md: disk1 new disk Apr 9 15:23:07 Tower emhttp: shcmd (11): cp /etc/exports- /etc/exports Apr 9 15:23:07 Tower emhttp: shcmd (12): killall -HUP smbd Apr 9 15:23:07 Tower emhttp: shcmd (13): /etc/rc.d/rc.nfsd restart >/dev/null Apr 9 15:23:09 Tower kernel: md: import disk1: [8,0] (sda) WDC WD10EACS-00D6B1 WD-WCAU44179194 offset: 63 size: 976761496 Apr 9 15:23:09 Tower kernel: md: disk1 new disk Apr 9 15:23:13 Tower emhttp: shcmd (14): /etc/rc.d/rc.samba stop >/dev/null Apr 9 15:23:13 Tower emhttp: shcmd (15): /etc/rc.d/rc.nfsd stop >/dev/null Apr 9 15:23:14 Tower emhttp: shcmd (16): hostname Tower Apr 9 15:23:14 Tower emhttp: shcmd (17): echo '# Generated' >/etc/hosts Apr 9 15:23:14 Tower emhttp: shcmd (18): echo '127.0.0.1 Tower localhost' >>/etc/hosts Apr 9 15:23:14 Tower emhttp: shcmd (19): cp /etc/exports- /etc/exports Apr 9 15:23:14 Tower emhttp: shcmd (20): /etc/rc.d/rc.samba start >/dev/null Apr 9 15:23:15 Tower emhttp: shcmd (21): /etc/rc.d/rc.nfsd start >/dev/null Apr 9 15:23:15 Tower kernel: md: import disk1: [8,0] (sda) WDC WD10EACS-00D6B1 WD-WCAU44179194 offset: 63 size: 976761496 Apr 9 15:23:15 Tower kernel: md: disk1 new disk Apr 9 15:23:15 Tower kernel: md: import disk1: [8,0] (sda) WDC WD10EACS-00D6B1 WD-WCAU44179194 offset: 63 size: 976761496 Apr 9 15:23:15 Tower kernel: md: disk1 new disk Apr 9 15:23:17 Tower kernel: md: import disk1: [8,0] (sda) WDC WD10EACS-00D6B1 WD-WCAU44179194 offset: 63 size: 976761496 Apr 9 15:23:17 Tower kernel: md: disk1 new disk Apr 9 15:23:17 Tower emhttp: shcmd (22): /etc/rc.d/rc.samba stop >/dev/null Apr 9 15:23:17 Tower emhttp: shcmd (23): /etc/rc.d/rc.nfsd stop >/dev/null Apr 9 15:23:18 Tower emhttp: shcmd (24): cp /etc/exports- /etc/exports Apr 9 15:23:18 Tower emhttp: shcmd (25): /etc/rc.d/rc.samba start >/dev/null Apr 9 15:23:18 Tower emhttp: shcmd (26): /etc/rc.d/rc.nfsd start >/dev/null Apr 9 15:23:18 Tower kernel: mdcmd (: start Apr 9 15:23:18 Tower kernel: md: import disk1: [8,0] (sda) WDC WD10EACS-00D6B1 WD-WCAU44179194 offset: 63 size: 976761496 Apr 9 15:23:18 Tower kernel: md: disk1 new disk Apr 9 15:23:18 Tower kernel: unraid: allocated 5048kB Apr 9 15:23:18 Tower kernel: md1: running, size: 976761496 blocks Apr 9 15:23:18 Tower kernel: mdcmd (10): check Apr 9 15:23:18 Tower kernel: md: recovery thread woken up ... Apr 9 15:23:18 Tower emhttp: shcmd (27): mkdir -m 700 /mnt/disk1 Apr 9 15:23:18 Tower emhttp: shcmd (28): mount -t reiserfs -o noatime,nodiratime /dev/md1 /mnt/disk1 >/dev/null 2>&1 Apr 9 15:23:18 Tower kernel: ReiserFS: md1: found reiserfs format "3.6" with standard journal Apr 9 15:23:18 Tower kernel: ReiserFS: md1: using ordered data mode Apr 9 15:23:18 Tower kernel: ReiserFS: md1: journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Apr 9 15:23:18 Tower kernel: ReiserFS: md1: checking transaction log (md1) Apr 9 15:23:18 Tower kernel: md: recovery thread has nothing to resync Apr 9 15:23:28 Tower kernel: ReiserFS: md1: replayed 284 transactions in 10 seconds Apr 9 15:23:28 Tower kernel: ReiserFS: md1: Using r5 hash to sort names Apr 9 15:23:28 Tower kernel: can't shrink filesystem on-line Apr 9 15:23:28 Tower emhttp: shcmd (27): cp /etc/exports- /etc/exports Apr 9 15:23:28 Tower emhttp: shcmd (28): mkdir -m 700 /mnt/user Apr 9 15:23:28 Tower emhttp: shcmd (29): /usr/local/sbin/shfs /mnt/user Apr 9 15:23:29 Tower emhttp: get_config_idx: fopen /boot/config/shares/DVD.cfg: No such file or directory - assigning defaults Apr 9 15:23:29 Tower emhttp: shcmd (30): killall -HUP smbd Apr 9 15:23:29 Tower emhttp: shcmd (31): /etc/rc.d/rc.nfsd restart >/dev/null Apr 9 15:23:35 Tower kernel: mdcmd (14): clear Apr 9 15:23:59 Tower kernel: mdcmd (17): clear Apr 9 15:37:34 Tower login[1093]: ROOT LOGIN on `tty1'
April 10, 200917 yr There are two common ways people post syslogs - one is to upload them as a file into the forums, and the other is to use www.pastebin.com. From what is posted here, this does not seem a "huge" syslog. It looks pretty normal for the 2nd half of the boot up portion of the syslog. About 1/2 way down there are thse two lines: Apr 9 15:23:03 Tower kernel: read_file: error 2 opening /boot/config/super.dat Apr 9 15:23:03 Tower kernel: md: could not read superblock from /boot/config/super.dat The super.dat file is where unRAID contains information about what drives are in the array and their states. If this file is missing than unRAID has lost its array definition. And if that is the case, the array will not start without going into the Web GUI and defining the array. Are you sure that you using the exact same USB stick to try to boot the array? Seems odd this one file would be missing. But should be easy to go back and redefine your array and have it rebuild parity. To help further, post a screenshot of the Web GUI.
April 10, 200917 yr When a syslog is too large to attach, it is generally recommended to zip it and attach the zip file, because compression of syslogs is very high, typically down to 7% to 10% of the original. (See the Troubleshooting link in my sig.) But in your case, this is only a tiny piece of what looks like a very small syslog, of perhaps only 50K, so you should not have had any problem. There is only one drive to setup, so unless it had a bear of a time identifying it (and there is no evidence it did), I don't understand how there could be anything more than 60K at most. Your syslog piece looks pretty good, with no real errors. The ones pointed out are normal for a brand new system (at least from the flash drive's point of view, just after preparation), or just after the Restore button was clicked. When the array was started, a number of transactions were replayed, indicating a bad shutdown the last time Disk 1 was mounted in the array, but that is no real problem. There are no drive errors or cable errors apparent here, but please do attach the rest of the syslog, as a zipped file, or on PasteBin. Until we see the rest of the syslog, the only thing I can think of, that might cause the copy failures, is corruption in the Reiser file system, particularly because there IS evidence of a bad shutdown. I recommend following the instructions on the Check Disk File systems wiki page.
April 10, 200917 yr Well I have been using these cables with my PC and xbox with no problem, The cables might have been fine, but you said you just moved. To me, that indicated you plugged and un-plugged the cables. That could have damaged them in some way, or caused a connection that was marginal to become intermittent. You did not indicate if you made the cables, or if they were purchased. You should be aware, there are TWO different ways to wire a cat5e cable. One is for telephone use, the other for LAN use. One wired for telephone use will either not work at all, or work poorly on a LAN. (A continuity test cannot tell the difference, it all has to do with which pairs of wires go to which pins) To complicate matters, many crimpers used to put the connectors on the ends are targeted for telephone use, so the drawings they supply are wrong for use on a LAN. If you followed the nice drawing that came with the crimper, you did it wrong. Next, cat5 is NOT good enough for 1000Mbit Lan, you must use cat5e or cat6. This even more difficult to determine with bargain cables purchased at the computer store. Often, all they say on the package is "length" with I just reformatted my pc to make sure it wasn't a problem with that (it was time for a clean up anyways). That gets rid of one problem, but introduces potential for another. Have you re-applied any operating system patches? Did you re-seat the connectors in the PC? A physical move could have loosened something up. I have the system log but it is huge! Without looking at the syslog the problem appears to be with the unraid server itself. It will stop copy data and then become unresponsive. Anyways how do I post the syslog, the forum says it is too many characters. These are the last few lines of the log. I have no idea how to make sense of this stuff. Others have already guided you to the troubleshooting section of the wiki where it describes how to save a copy of the syslog. A zipped copy can be attached to your next post. The section you posted was after rebooting, but before the slowdown and disconnect you described. We need to see a syslog after the problem occurs, but before you reboot. You might want to upgrade to 4.5-beta3, as it allows you to browse to the syslog by typing //tower/log/syslog in your browser. Joe L.
April 10, 200917 yr Author I have attached the syslog. This log goes from startup to the error. As for cables, all my cables are store bought with connectors. The cable to my main PC has been plugged in for 2 months now and I have no network or internet issues. The cable I plugged into the unraid server was replaced by the cable that went to my xbox which has also been working for 2 months. I swapped the cables after you said they might be bad so I removed the newest cable with a know good one. I have also removed and reseated all cables. Also, since my last post, I moved to the beta as the recommendation posted.
April 10, 200917 yr Unfortunately, I don't have time just now to analyze or write more, but something is seriously confusing unRAID about that drive. I would recommend running the Preclear Disk procedure on it, removing super.dat from the config folder of your flash drive, and restoring the original disk.cfg (from the latest unRAID distro). Basically starting over, with a fresh disk and fresh config ...
April 10, 200917 yr I have attached the syslog. This log goes from startup to the error. As for cables, all my cables are store bought with connectors. The cable to my main PC has been plugged in for 2 months now and I have no network or internet issues. The cable I plugged into the unraid server was replaced by the cable that went to my xbox which has also been working for 2 months. I swapped the cables after you said they might be bad so I removed the newest cable with a know good one. I have also removed and reseated all cables. Also, since my last post, I moved to the beta as the recommendation posted. OK, now the syslog shows what is going on. You need to follow the advice given by RobJ in his FIRST post to you. Your file-system on the disk is probably in need of repair. The corruption is triggering a kernel error. It appears as if you might not have stopped the array cleanly, or perhaps you lost power at one point... but the problem is easy to fix. It has nothing to do with your LAN cables... Since you have no parity disk, it will be really quick. Your data disk is on /dev/md1 Follow the steps in the wiki... http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems You might also want to get a SMART report on the disk, just in case it is having a hardware problem. See instructions here: http://lime-technology.com/wiki/index.php/Troubleshooting#Hard_drive_failures (From what I saw in your syslog, your physical drive would be /dev/sda )
April 10, 200917 yr Unfortunately, I don't have time just now to analyze or write more, but something is seriously confusing unRAID about that drive. I would recommend running the Preclear Disk procedure on it, removing super.dat from the config folder of your flash drive, and restoring the original disk.cfg (from the latest unRAID distro). Basically starting over, with a fresh disk and fresh config ... I would try a reiserfsck first... If it cannot be done on /dev/md1, then stop the array and try it on /dev/sda1 (note the "1" on the end)
April 11, 200917 yr Author I did the steps you guys said and it works now, when I did the reiserfsck it found 1 error, and allowed me to format the harddrive, prior to that formatting the drive wasn't an option. Thank you both very much for your help!
April 11, 200917 yr Unfortunately, I don't have time just now to analyze or write more, but something is seriously confusing unRAID about that drive. I would recommend running the Preclear Disk procedure on it, removing super.dat from the config folder of your flash drive, and restoring the original disk.cfg (from the latest unRAID distro). Basically starting over, with a fresh disk and fresh config ... I would try a reiserfsck first... If it cannot be done on /dev/md1, then stop the array and try it on /dev/sda1 (note the "1" on the end) The reason I thought starting over might be better, was that there was also a "write MBR" in there, unusual to say the least! This was after it had identified the disk and read the partition table and found one partition (sda1). Plus, it then mounted the disk and replayed ANOTHER 427 transactions, before crashing the Reiser file system. Since I didn't think he had any real data on the drive yet, it just seemed easier to start fresh. kasm: Most likely, these crashes are resulting in the replayed transactions (which indicate a bad shutdown), but I thought I would remind you that, if possible, try to stop the array first, before powering down.
Archived
This topic is now archived and is closed to further replies.