myce

Glad I could help. The patch has now been applied to bergware's original version. Don't forget to switch back to his version in order to receive further updates.

I had the same problem after upgrading from 5.something to 6.2. You are right in assuming that the sleep script doesn't find the powerdown script. After finding out how to modify a plugin with some trial and error (Is there any documentation about the correct procedure to set up a plugin for unRAID 6?) I came up with this solution. It calls the powerdown script using the full path. Please install it from here: https://raw.github.com/rgls/dynamix/master/unRAIDv6/dynamix.s3.sleep.plg and try if it solves your problem as well. You'll have to uninstall the original version before installing this one.

Some further findings: I had a file named shfs in the root directory of the flash drive. (Don't ask why. I copied some scripts from a backup of an old version of unraid to the flash and must have copied shfs as well.) Renaming the file and rebooting made unraid act normally again. I don't really understand why. As shfs was started by emhttp (and later manually) with the full path, the file in the root of the flash drive shouldn't have interfered here. Why is shfs influenced by some file in an unrelated path? Is this some kind of plugin or hooking mechanism? Maybe someone with insight into the source code could shed some light here.

Hello all, my unraid server just stopped sharing it's shares. Yesterday everything was working as expected. The server was shut down normally and without problems. Today xbmc couldn't find the shares. A quick check with a windows machine confirmed that the server wasn't sharing. I logged onto the server and was glad to see that all files where still there. But the shares were not mounted under /mnt/user/ . A check with ps revealed that shfs was not running. The syslog (see attachment) showed the following lines: Dec 10 14:11:43 Kanga emhttp: shcmd (34): mkdir /mnt/user Dec 10 14:11:43 Kanga emhttp: shcmd (35): /usr/local/sbin/shfs /mnt/user -disks 16777214 -o noatime,big_writes,allow_other -o remember=0 |& logger Dec 10 14:11:43 Kanga logger: fuse: invalid argument `16777214' It is quite clear that emhttp tries to start shfs with some invalid arguments. If I start shfs by hand using: /usr/local/sbin/shfs /mnt/user -o noatime,big_writes,allow_other -o remember=0 |& logger leaving out the offending argument, everything works ok. Where does the value for the disks argument come from? What can I do to fix this situation? unraid_syslog.txt

No, that's not what is happening in my case. Even after closing the browser (Firefox in my case) I wasn't asked for a password the next time I connected to the web-if. Even accessing the web-if from a different browser on a different machine didn't get me a password prompt. unRAID just let me into the web-if without requiring a password. But it's kind of solved now: I changed the password using the web-if, then changed it back. Now everything works as expected: I'm asked for a password when connecting to the web-if. I might have changed the password in the shell, but the password survived reboots of the server, so I probably did use the web-if to set it after the upgrade. Anyway: Under certain conditions unRAID doesn't ask for a password in the web-if. It seems this can be fixed by setting the password again.

I upgraded from 4.7 to 5.0 recently. In 4.7 the web-if required me to login as root using the password I use for shell logins. After the upgrade, I'm no longer asked for a password. Is that intentional, or do I have to tick a checkbox to get the old behaviour? Regards, myce

I intended to upgrade my unraid from 4.5-beta8 to 4.7. Before I started I thought a parity check might be a good idea, considering that the last one was done over a years ago. It showed one sync error right from the beginning. I looked in the syslog, expecting to see which sector was invalid but found nothing. All there was, was: Oct 17 19:49:45 Kanga kernel: mdcmd (8 ): check Oct 17 19:49:45 Kanga kernel: md: recovery thread woken up ... Oct 17 19:49:45 Kanga kernel: md: recovery thread checking parity... Oct 17 19:49:45 Kanga kernel: md: using 1152k window, over a total of 1953514552 blocks. Shouldn't the sector with invalid parity be logged? Any options I missed? If it matters, I started the check from the main page of the standard webui. Regards, myce

Thanks. Am I right that the procedure would be different if I had already updated to 4.7? I seem to recall reading something about the Restore button being removed and a shell script (initconfig or something along the line) took it's place. myce

Hi! After replacing a drive by a bigger one, I need to go back to the previous configuration. How do I do this safely? What I wanted to do: Replace my 1.5 TB parity drive by a new 2TB parity drive and replace one of the 1 TB data drives in the array by the former parity drive. What I did: Before I started, I did a parity check, which turned out OK. So I'm reasonably confident that the data drives are in good condition. I powered down the system, replaced the parity drive, restarted and let unraid do a parity synch. After that finished, I powered the system down again, replaced one of the data drives by the former parity drive and started a disk rebuild. What happened then: I realized that my new parity drive had a firmware bug (Samsung F4) and the parity data wasn't reliable. I stopped the rebuild, powered down the system and replaced the 1.5 TB drive by the old 1 TB drive My problem: unraid tells me that the new disk (which is in fact the old disk) is to small. So my situation is: I have a bunch of data disk, which I'm convinced are good. No parity data, but that could be rebuild if unraid would accept the old data drive. So, am I right that I should: Tell unraid that it should accept the smaller drive. Rebuild the parity on the old (1.5TB) parity drive. Start over, once I get a new, reliable 2TB drive If that's true, how do I do it? I'm using 4.5-beta8 (Yeah, haven't updated in a while. Planned on doing it after the drive upgrade...) Would Leaving the 1TB disk in the array. Replacing the parity drive by the 1.5TB drive. (Thus restoring the old configuration) checking "I'm sure I want to do this" and hitting "Restore" be the right thing to do? I guess I'll have to tell unraid to resynch parity after that. Regards, myce

Here is the promised patch. Took a while longer as I had to rescue our cat first... The comment starts in line 274 in my version of rc.S # Mount non-root file systems in fstab, but not NFS or SMB # because TCP/IP is not yet configured, and not proc or sysfs # because those have already been mounted. Also check that # devpts is not already mounted before attempting to mount # it. With a 2.6.x or newer kernel udev mounts devpts. # We also need to wait a little bit to let USB and other # hotplugged devices settle (sorry to slow down the boot): # myce -- loop instead of delay echo "Mounting non-root local filesystems:" mountloop=0 while [ $mountloop -lt 60 ] && ! fgrep -q "/boot" /etc/mtab do sleep 1 mountloop=$[$mountloop+1] if /bin/grep -wq devpts /proc/mounts ; then /sbin/mount -a -v -t nonfs,nosmbfs,nocifs,noproc,nosysfs,nodevpts else /sbin/mount -a -v -t nonfs,nosmbfs,nocifs,noproc,nosysfs fi done # tmm - Set the configured timezone, must be after flash is mounted on /boot

This is probably to late to incorporate into the 4.5-final. I have a fix for rc.S not reliably mounting the USB stick. My system didn't always mount the USB stick when it booted. The reason for this is that the delay before doint the "mount -a" was too short. As the comments in rc.S suggest, tmm did already raise the delay to five seconds. But that was still to short for my system, especially if there were more than one USB-drives connected. Instead of raising the delay even more, I made the script retry mounting until the drive with the label UNRAID was detected (or a maximum number of loops had been done). While this makes the booting more reliable for slow USB drives, it would speed up booting for some people as the initial five second delay is no longer needed. I'm in the office right now, but I could post my patch in a few hours time. It would be nice if this could be part of future versions. Regards, myce