So,

 

My unraid machine, shuts down on a night. (Full shutdown not sleep)

The past few days (maybe a week), i come home from work, turn the girl on, and when I goto use it, theres nothing there.

So i log in to the webui, and my shares are unavailable, and the docker service failed to start.

 

I dont think, I've done anything besides update, dockers, and plugins. I did tweak a couple of shares' SMB settings, but thats about it.

 

I do run a tweak to my boot up. I run an FTP server on my phone, when th eserver boots up, she looks for my phone, and pulls the password. But this has been the case for 2 years now. I know, i know. But its no more insecure than anything else. It stays on my phone and is only accessible from my local network. It just saves me from having to log into the webui every bloody day, just to unlock the thing.

 

The fix for this, seems to be to reboot. But obviously i dont want that.

 

I've added my diagnostics, any help finding the culprit would be very much appreciated

First (...1403) is after a cold boot. 18hrs shutdown

Second (1506) is taken after rebooting the machine, and received no errors

hal-9000-diagnostics-20201223-1431.zip

hal-9000-diagnostics-20201223-1506(AFTER REBOOT).zip

Edited December 23, 20205 yr by 7hr08ik

This starts before the disks are mounted:

 

Dec 23 14:24:08 Hal-9000 emhttpd: error: get_filesystem_status, 6618: Operation not supported (95): getxattr: /mnt/user/# Backups - Rob

 

Does it ring any bells? If not try booting in safe mode.

I did see that, and that is one of my shares. But i have no clue what it means.

Obviously its telling me that "getxattr" has failed, on that share. But what is it? Is something i did, something i can fix? Is my drive screwed? And why is it only happening on a cold boot? Why not every boot?

I've added a second diagnostic.

 

The first is from a cold state. She was shutdown for at least 18 hours. Failed on boot.

The second (I have marked) is from a reboot, and gave me no issues (besides the obligatory parity check)

 

 

 

Could be some plugin, try booting in safe mode.

I'll try give that a go tomorrow, if i rememeber. Its just very strange that it only happens after the machine has been shutdown overnight.

 

I would like to just sit here and do lots of reboots, and see if its repeatable at all. But I  dont know if that gonna cause any more issues, or break something

3 minutes ago, 7hr08ik said:

Its just very strange that it only happens after the machine has been shutdown overnight.

That is odd.

So, if i do infact sit here for an hour and reboot the system, again and again. Cancel the parity check, try with and without the FTP from my phone. Could i break anything? I mean if it does, again, not start up the shares and docker, could i do damage to anything? I mean, could i be risking losing the shares, or corrupting the dockers?

 

I just want to be certain, its only after cold boots. It might happen if i shutdown and startup, instead of a reboot. But i dont want to risk my data obviously

So, i shutdown, and started up again. No issues at all.

So, i just checked the app store, and theres a mark against S3 Sleep. Apparently it has issues. Perhaps thats my problem

Aaaaaaaand its back!

 

System was shutdown overnight. Came home from work, and started the system as I do everyday.

 

Shares and docker are not starting up. I've attached a diagnostic. I did remove S3-sleep, and this seemed to do the trick for a while.

missing-shares--hal-9000-diagnostics-20210113-1726.zip

To clarify,

 

I turned the system on, found the shares and docker had not started up. Got the diagnostic. Rebooted. And everything is OK.

 

What could possibly be happening? If it was my car, I would be thinking the cold is making the starter motor seize up.

In those diagnostics, your user shares had not mounted for some reason, which is the cause of the other issues.

 

Not clear though why. Take a look at your flash drive in config/shares folder. You have a very large number of .cfg files for user shares, many I suspect don't actually exist and were probably created at some point when you accidentally (or on purpose) specified a path at the root of cache or an array disk, such as in a docker mapping. Any folder at the root of cache or array is automatically a user share.

Hi,

 

I know the shares not mounting is the issue. My problem is that it is not a repeatable issue. For instance, yesterday the system booted up and gave me issues. Today, the system booted up, and not a single problem. And the weirdness of how a reboot, will always, every time, fix the problem.

 

I think I know what those shares are from. I just looked at them, and they are all random names (blue, shallow, carp, etc) There was a time, a long time ago, that i used the anti-ransomware plugin, and if memory serves, it would create a while bunch of new shares/files/folders. Am I just to simply delete all the unwanted config files?

 

 

1 minute ago, 7hr08ik said:

Am I just to simply delete all the unwanted config files?

Yes.

 

If you accidentally delete one for a share you still have it just means that a new .cfg file will later automatically be created for the share and it will have reverted to the default settings.

OK, so i've removed the erroneous .cfg files. Now i just have 1 for each of the shares I have.

Usually in syslog you will see each data disk mount in order, then each pool (cache) mount, then user shares (and user0) mount, then the vdisks for docker.img and libvirt.img mounts.

 

In your case, after cache mounts, instead of the attempt to mount user shares, you are getting these errors:

Jan 13 16:56:18 Hal-9000 emhttpd: error: get_filesystem_status, 6618: Operation not supported (95): getxattr: /mnt/user/# Backups - Rob

Do you have something that might be trying to access that path before it exists?

I dont think so. I have plugins, and dockers, but they wont do anything until after its all booted up.

 

Apart from that I have my other rig, that backs up to there, but thats all SMB, so shouldnt really matter if the location doesnt exist yet.

 

I do have a small cheap chineezium HBM in there (PCI-E, 2xSATA, and even an IDE) . If thats where my cache is installed, then i think we have our culprit. Perhaps that would explain the randomness of the fault

Edited January 14, 20215 yr by 7hr08ik

42 minutes ago, 7hr08ik said:

Apart from that I have my other rig, that backs up to there, but thats all SMB

What more can you tell us about that?

I have Duplicati set to backup from my rig to unraid. It runs fine, as far as i know.

Is everything working currently?

Yeah, everything with duplicati works great and has done for over a year now. Even restored from it a time or 2

no I meant everything, such as the problem you started this thread for 

Oh sorry.

 

Yes everything runs fine. All my dockers do as they should, plugins work as intended. Backups from other systems to the server run great.

 

There has only been 2 issues for me, ever. This current issue, of random non-starting shares, and one other. I added a second cache drive (same size and even model as current cache) but when starting the system, the dual-cache would fail to start. So i just removed the second cache drive and forgot about it. But the more time I spend figuring this all out, the more I think it's related to the cheap HBM card I have installed.

 

Unfortunately, due to the random nature of my problem, it is hard to definitively change and test any possible fix. The only thing I can do is replace the HBM card with something a bit more reputable, and see if my issues go away. (After a few weeks/months)

Been doing some reading and i think im gonna grab LSI 9211-8i card and some SAS>SATA cables. Then keep the parity and cache drives on the mobo, put the array drives on the card?