[SOLVED] Shares not mounting after restart

My 5.03 box has been running uninterrupted for about 8 months now. I was troubleshooting an oddity with sabNZBd not passing things back to Sickbeard correctly and I decided to give the whole shebang a fresh reboot. I stopped the array and triggered a reboot from the GUI. After unRAID came back up again I logged into the webGUI and restarted the array. Everything seemed to be behaving as normal when I noticed a few minutes later that the webGUI page still hadn't refreshed. I stopped the page load and tried to go back to the unRAID GUI but it still wouldn't load. It never fails, it just sits there waiting to load.

I took a look at my SMB shares and found that they were all missing. Not exactly all, as the share for my flash is still there, but all other SMB shares are gone. I SSH'ed into the box and took a look at the SAMBA config but I don't see anything out of the ordinary. It makes sense to me that my SMB shares aren't there if the array won't start but I can't seem to figure out why the array isn't starting in the first place. Having read a few posts from others that are having similar issues. I removed my secrets.tdb file and rebooted without any decent results. I disabled unMenu in the go file and tried another reboot but no joy. I manually launched unMenu and it claims that the array is started. When I try to click on the MyMenu tab in unMenu it locks up and fails just like the unRAID GUI. I tried stopping the array from unMenu and then going back to the unRAID GUI but it still wouldn't start. I tried killing emhttp and starting it again but that didn't change anything either.

Lastly I reformatted my flash, reinstalled 5.03 and copied my backup configuration but still got the same result. Just for fun, I tried that again but reinstalled 5.06 and copied my backup configuration into place but I'm still looking at the same issue. unRAID seems to start fine, and I can start the array via the webGUI but once I do that, I lose access to the webGUI and my shares still don't export.

I haven't made any changes to unRAID in a good long time. I can only assume that something that I've tried to change in the past is causing me some trouble and has only now reared its head due to the restart.

Has anyone got any suggestions? I think I may have run out of ideas. I've tried posting my syslog but it seems that there are enough packages loading that the syslog is too large by the time all is said and done.

Ultimately I found that if I powered unRAID up and went into maintenance mode, I could witness the parity check that resulted from my power offs rather than the GUI becoming unusable. Presumably the issue is with exporting the shares and doing the parity check at the same time. I'm going to let it finish up the parity check (6 hours to go) and then try starting the array again and see if it behaves itself then.

The parity check finished up overnight and everything checked out fine. Now I'm back where I started. When I try to start the array, the webGUI browser tab shows that it's connecting but never does. It seems that when unRAID tries to start the array everything goes for a crap. I'm hoping that documenting all of this here will help some other poor soul.

With the webGUI spinning away in my browser I logged into unRAID via SSH to watch the syslog scroll by

tail -f /var/log/syslog

For whatever reason I noted that the CouchPotato plugin was the last thing in the syslog and it was going no further. When I killed CouchPotato then other processes like SAMBA, SickBeard and sabNZBd began loading. I still couldn't get the webGUI back again so I set out to restart emhttp. Much as I found in my earlier experimentation, I was still unable to restart emhttp in the manner that seems to be documented everywhere. I could kill the process, but attempting to run emhttp manually resulted in a segmentation fault. Figuring I might as well reboot to ensure CouchPotato was truly disabled, I removed the CouchPotato plugin from the flash and set about restarting via the command line.

Note to all, the instructions commonly found on the 'Net for restarting via the command line are for a base model unRAID without any plugins.

To stop the array you must stop samba (since otherwise it would keep the disks busy)

/root/samba stop

 

then, you must un-mount each of the data drives

umount /dev/md1

umount /dev/md2

etc

 

Then you can stop the array

/root/mdcmd stop

 

To restart the array at that point, the easiest, and what I do, is type:

reboot

These step above won't work for anyone running additional plugins as they retain a hold on the drive mounts. You'll need to stop your plugins before you can properly shut down.

/etc/rc.d/rc.samba stop
/etc/rc.d/rc.sickbeard stop
/etc/rc.d/rc.sabnzbd stop
/etc/rc.d/rc.mysql stop

With all of those processes stopped, now you can unmount the disks.

 umount /dev/md1
umount /dev/md2
.
.
.

There should be a dev device for each storage disk in your array. If you type "umount /dev/md" and then press TAB twice you'll see just how many disks you have that need to be stopped. In my case most of my disks are md#, some are sdx#. If you type "mount" at the command line you'll see what disks are mounted on the system and will learn if they are md1, sdb1, etc. Execute the umount command above for each disk. If typing that command results in a warning that the disk is in use, that means that there are still processes running that are using the disk and they will need to be stopped in order to continue.

With all processes stopped and disks unmounted now unRAID can be rebooted

reboot

Since I had uninstalled CouchPotato my array came back up just fine. I've no idea yet what caused the problem but I've got my shares and my webGUI back and all seems to be well in my world again. 

Feel free to update the wiki with this info.

Most of it appears to already be there, apart from mentioning that other plugins will leave processes running that can prevent the disks from being unmounted.

The wiki appears to be locked at the moment. Something to do with username handling. I'll try and check back later and see if the wiki is unlocked.