I'm using 4.5 final.

 

We had a power outage today, and my fiance called me letting me know the server was beeping (she was hearing the UPS complain). I had her hit the power button (hoping it'd execute a clean shutdown), but she pressed the reset button on the front of the machine (I guess I wasn't clear enough).

 

Once the server came back up, I noticed a parity check started (as I expected), but for some reason nearly all my user shares are gone. Only one of my eight or so user shares appears to be still showing up (in the GUI and in /mnt/user). The files still seem to exist on my drives, because if I browse by /mnt/diskX the folders and files are there, but /mnt/user only shows the one user share.

 

I'm not really sure what's going on, but since the system is running a parity check, I'll let it keep doing that for a while, then see what caused the user share issue.

 

Is there any particular place I should focus my efforts on - trying to resolve this, and trying to prevent it again in the future?

 

Thanks!

I just mounted /tower/flash and took a look in config/shares. All 7 of my shares have .cfg files in there, and examining them, they look identical to each other (I use nearly the same set of settings on each one). I'm not sure why one of the seven works but the rest refuse to.

So I got a little impatient, and cancelled the parity check (I know, bad practice!). I then powered down the system and re-powered back up. unRAID came back up with all my user shares.

 

I'm not sure if it caused it, but my prior syslog had a mention of

Dec 30 17:32:58 Tower emhttp: shareCount not found

 

This same error was not in my new syslog after I rebooted and user shares worked.

 

I'm re-running a parity check now.

I forgot to update this when it happened, but parity checked out fine. I'm still not 100% sure what happened, but I think it has something to do with the array not being 100% online when my add on packages start installing/loading.

While I don't use User Shares, I have seen this happen a number of times, after a crashed session.  For me it is typically cache_dirs that starts before all drives have finished mounting, and therefore only some of the drives are 'cached' then.  Any drives taking too long to mount are not included.

 

It happens because after a crash, there are transactions to be replayed by the Reiser file system, and if writing to the disks was being performed at the time of the previous crash, there can be quite a lot of transactions to be replayed.  The mounting of a drive is not completed until all transactions have been replayed.  What especially exacerbates this is that a parity check is also performed, immediately on booting of the array, even before the drives are mounted, and because of the maximum I/O happening on all drive busses for the parity check, this makes all simultaneous transaction playback MUCH slower than normal, often several minutes!  unRAID seems to have a set time to wait for the drives to finish mounting, and at the end of the wait, proceeds to continue with all other setup tasks.  In your case, the User Shares setup probably started before most of the drives had finished mounting, so only drives that were completely mounted at the moment it checked were included.  Probably you only had to stop the array, then restart it to restore the full User Share system.  A reboot is even better, and a complete parity check was a good idea.