I have a feeling there's a simple fix to this. But I can't find it in the 'board.

 

I had a drive bomb out. It's old and probably needs replacing, but the SMART doesn't indicate that it's totally dead yet; I think the heat killed it yesterday. I pulled it out of the array, put it back in the array and started the rebuild. All's well there.

 

Only thing that happened while doing that was some "hangs" trying to power off; I hit the "power off" button at one point when it wouldn't shut down. (I think I found a reliable way to do that since - by using the "Stop Array" button in UnMenu's Array Management.)

 

All seemed well with the rebuild... until I went to check the data... and there are no shares accessible from SMB. Okay... that happens, right? Checked the shares under the main menu screen. Not there. Hmmm...

 

I've done this rebuild stuff before. The data is typically available and all is working (if a little slower).

 

Good news is that all the data shows on the drives (telnet in and look in mnt/disk*).

 

Weird thing is that mnt/user is empty; but mnt/user0 has all the shares in it. Is that normal? Is this where the problem is?

 

How to fix it?

How to fix it?

I have a  problem,  I think it something is wrong in my car, what part do I need to buy?

 

As hard as you would have to work to answer my question, we would for yours.  You did not provide a syslog for analysis, nor even mention the version of unRAID you are running.

 

Basically, once things settle down, reboot. Stop all your add-ons PRIOR to stopping the array.  Using the button in unMENU is a last-ditch effort, as it KILLS everything, without waiting for a clean exit if the KILL signal is not properly handled.

 

More than likely you ran out of free memory and the shared file system crashed or was killed.

 

Joe L.

Sorry. I guess I missed the post on "please list each of these things when asking for help or admit that you're a moron." Obviously, I should provide the syslog and mention which version of unRAID. It does seem obvious now that you mention it. And it is in the "please list these things" post. My bad.

 

I admit I didn't even think about the version because if I was on the beta code I would have provided the version and posted in the appropriate forum; but I sort of assumed everyone would be on 4.7 if they're not on the beta. My bad. I'm on 4.7; is there a sub-version I should know about or be able to see somewhere? I have been solid on 4.7 since release; and the only changes (and only shut-downs) since 4.7 release have been to replace drives.

 

The syslog is attached as well - since the latest boot, I think. Maybe I'm not doing it right. Not sure.

 

I have shut down almost all add-ons; but there are a number that appear to be part of the system even though they show in the UnMENU Pkg Manager screen. Again, I'm clueless here; just doing the best I can.

 

 

======

 

On my original track, I was trying to point toward what is and is not working, since I suspect that the user-shares aren't finding the file(s) that make them load. I know from looking at the disks that all the data is there. The rebuild finished and everything says it checks out fine. But I don't understand diddly about how this stuff works from there.

 

There are a couple of posts that talk about how the shares work and what can typically be done when they don't show; though they seem to be oriented around SAB and/or other services running (which are not). I was thinking it might be something similar.

 

I suspect that the issue was caused by the dirty shutdown; which is why I was thinking someone knowledgeable could point me to whatever file may be corrupt to cause this.

 

 

Since the syslog is here, perhaps you can also look for why the "find" process is having files open and not letting go of them. I have waited tens of minutes for a shutdown, only to watch (with lsof and fuser) the find process keep moving from one file or directory to another. This is something new; I have not had or seen this issue over the last couple of years - though I suspect it is related to the cache drive and/or mover script. Since these are the only files open, I really didn't expect the dirty shutdown to cause a problem.

syslog.txt

Adding one more piece here: the "disk*" shares work, BTW. I can get to "\\unraid1\disk1\" and the like from other computers. And the .cfg files are all in the /boot/config/shares/ folder. ugh.

Sorry. I guess I missed the post on "please list each of these things when asking for help or admit that you're a moron."

I did not call you a moron.

    Obviously, I should provide the syslog and mention which version of unRAID. It does seem obvious now that you mention it. And it is in the "please list these things" post. My bad.

No problem.

I admit I didn't even think about the version because if I was on the beta code I would have provided the version and posted in the appropriate forum; but I sort of assumed everyone would be on 4.7 if they're not on the beta. My bad. I'm on 4.7; is there a sub-version I should know about or be able to see somewhere? I have been solid on 4.7 since release; and the only changes (and only shut-downs) since 4.7 release have been to replace drives.

Glad 4.7 has worked well for you.    There are only two bugs I'm aware of in it.  Just be very careful if you have to replace the flash drive.  unRAID 4.7 has difficulty in determining how a disk was originally partitioned if the config/super.dat file is missing.  If you see disks showing as un-formatted, do NOT just decide to "Formst" them unless you want the data on them to be erased.  Also, do not write to a disk being re-constructed while the re-construction is in progress.

 

There are tons of people with older releases than 4.7.  In the same way, they are being served by their unRAID servers just fine.  If they have had no need to upgrade,many have not.  The release is VERY important when asking for support.  Many things have changed over the years. Some releases have VERY SERIOUS bugs that can byte you, when you least expect it.

The syslog is attached as well - since the latest boot, I think. Maybe I'm not doing it right. Not sure.

 

I have shut down almost all add-ons; but there are a number that appear to be part of the system even though they show in the UnMENU Pkg Manager screen. Again, I'm clueless here; just doing the best I can.

True, at one point some of the programs now supplied in unRAID's stock release were not part of the release at all.  For those, they will now show as installed, even if you did not, as lime-tech is now including them in the standard release.  Often they even will be an newer version.

On my original track, I was trying to point toward what is and is not working, since I suspect that the user-shares aren't finding the file(s) that make them load. I know from looking at the disks that all the data is there. The rebuild finished and everything says it checks out fine. But I don't understand diddly about how this stuff works from there.

User-shares always include every top level directory.  If /mnt/user is empty, the shfs file-system process crashed.  It is the virtual file-system.

There are a couple of posts that talk about how the shares work and what can typically be done when they don't show; though they seem to be oriented around SAB and/or other services running (which are not). I was thinking it might be something similar.

It is different.  All you can do is reboot.  I know of no way to re-start the shfs file-system.  (about all you could try is to stop and re-start the array.)

I suspect that the issue was caused by the dirty shutdown; which is why I was thinking someone knowledgeable could point me to whatever file may be corrupt to cause this.

It is not a file.It is a process that has died.

Since the syslog is here, perhaps you can also look for why the "find" process is having files open and not letting go of them. I have waited tens of minutes for a shutdown, only to watch (with lsof and fuser) the find process keep moving from one file or directory to another. This is something new; I have not had or seen this issue over the last couple of years - though I suspect it is related to the cache drive and/or mover script. Since these are the only files open, I really didn't expect the dirty shutdown to cause a problem.

The "find" will run every three to ten seconds, that is by design.  If your directory structure is so deep that it takes tens of minutes for a find to complete, perhaps you should check the file-system itself. (instructions on how are in the wiki)

 

While the disks are busy (a file open, or the current-working-directory of a process)  they cannot be un-mounted.

  Until they can be un-mounted, the array will not stop.

 

The cache_dirs script checks in between each "find" command to see if it sees error messages in the syslog showing an attempt to stop the array,but disks are busy.  If it finds one, it suspends itself. 

 

Your problem is something is causing a listing of files to take a much longer time than usual.  It could be a bad disk, , a bad cable, a inadequate power supply, or even a corrupt file system.

This seems odd:

Aug 19 18:57:55 UNRAID1 logger:  /usr/sbin/exportfs -r

Aug 19 18:57:55 UNRAID1 exportfs[2686]: /etc/exports:2: unknown keyword "r"

Apparently,you have the NFS exports incorrectly defined. 

Thanks, Joe. The moron reference was to myself. I was feeling stupid. Rightfully. And sassy. Not rightfully.

 

So... if that's the virtual file system that's crashed and rebooting doesn't help, what to do? It wasn't clear from the syslog what's up?

 

The "disk" shares work. But the ones I built do not. I re-configured to show the shares (they were hidden) and they're easy to attach to from a Windows system now.

 

I took a chance and created a "videos" share to see if it would map back to the top-level "videos" folder(s). It shows in the /mnt/user folder. And it shows when I look at the \\unraid1\ system from a Windows system, but it's empty. And rebooting doesn't seem to change things. I'm happy to rebuild all the shares if that will work; but it didn't with this first test. Something I can do to change that?

 

Uh... I'm stuck. Any other diagnostics I can do or provide?

I don't know of doing anything to NFS shares. Maybe that's what went wrong? Any ideas what to do?

 

I could be wrong... but I don't recall ever using the NFS shares. I may have tried to use it to backups with my other NAS at some point; but I don't know what config it might have had at this point.

I don't know of doing anything to NFS shares. Maybe that's what went wrong? Any ideas what to do?

Well,

*(rw)

is valid for read/write access

and

*(ro)

is valid for read-only access

but you have

*®

which is not valid.

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (60): echo \"/mnt/disk3\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=13' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (61): echo \"/mnt/disk4\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=14' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (62): echo \"/mnt/disk5\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=15' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (63): echo \"/mnt/disk6\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=16' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (64): echo \"/mnt/disk7\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=17' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (65): echo \"/mnt/disk8\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=18' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (66): echo \"/mnt/disk9\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=19' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (67): echo \"/mnt/disk10\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=20' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (68): echo \"/mnt/disk11\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=21' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (69): echo \"/mnt/disk12\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=22' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (70): echo \"/mnt/disk13\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=23' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (71): echo \"/mnt/disk14\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=24' '*®' >>/etc/exports (Other emhttp)

Aug 19 18:57:51 UNRAID1 emhttp: shcmd (72): echo \"/mnt/cache\" '-async,no_subtree_check,anongid=0,anonuid=0,all_squash,fsid=10' '*®' >>/etc/exports (Other emhttp)

Hate to be stupid... but I don't know how that got there or how / where to change it.

 

Hmm... I wonder if that's some left-over from back before there was a "hidden" option for the disk and flash shares. I recall changing stuff to try to make them hidden. Dunno. If it's a change I made, it's been years.

 

Either way, that's on the disks, not on the shares, right? And on NFS, not on SMB? How to get the SMB shares back and working again?

I didn't open the logs or anything but the last person with the issue of the shares appearing in the user0 directory but not appearing in the user directory had a problem with the cache disk. For fun, try unassigning the cache disk and re-starting the array.

 

 

WOO-HOO! That did it! You are AWESOME! Thank you!

 

I stopped the array (eventually) and removed the cache drive.

Restarted the array and everything was as it should be: shares were all restored.

 

I'm guessing that means the cache drive is corrupt in some way.

Probably need to run a check-disk of some sort, I'm guessing?

Is that the reiserfsck command? or is the cache not Reiser?

Anyone know? Or i can search the wiki... come to think of it.

If you have no files left on the cache drive, I'd preclear it and let unraid set it back up when you reassign it to the cache slot. If you have files you need to recover, then yes, a file system check is in order.

The Reiserfsck commands to use are in the Wiki. You will have to use the device name and don't forget the 1 on the end to tell it to check the first partition - "sdg1" for example.

 

You could also preclear and re-add or use the dd command to erase the first part of the disk and add it again.