User Shares Missing after update to 6.6.1

[ZEBaker98]

I have just recently updated to UnRAID 6.6.1 and all of my shares have dissapeard. After checking the logs I noticed the same error is being repeated every few seconds.

Oct 8 19:43:55 Tower emhttpd: error: get_filesystem_status, 6477: Operation not supported (95): getxattr: /mnt/user/Tower-NAS
Oct 8 19:43:55 Tower emhttpd: error: get_filesystem_status, 6477: Operation not supported (95): getxattr: /mnt/user/appdata
Oct 8 19:43:56 Tower emhttpd: error: get_filesystem_status, 6477: Operation not supported (95): getxattr: /mnt/user/Tower-NAS
Oct 8 19:43:56 Tower emhttpd: error: get_filesystem_status, 6477: Operation not supported (95): getxattr: /mnt/user/appdata

All of the data appears to be intact on the hard drives but all of the shares are missing. Thanks in advance for any help.

tower-diagnostics-20181008-1939.zip

Edited October 9, 2018 by ZEBaker98
removed html formatting

[bonienl]

Are you using ReiserFS?

[limetech]

12 hours ago, ZEBaker98 said:

All of the data appears to be intact on the hard drives but all of the shares are missing. Thanks in advance for any help.

I think this is a problem with that networkstats plugin.  Please remove and/or boot in Safe Mode to confirm.

[pluginCop]

On 10/9/2018 at 11:25 AM, limetech said:

I think this is a problem with that networkstats plugin.  Please remove and/or boot in Safe Mode to confirm.

Once problems became apparent with the network stats plugin (Oct 7th), a mod comment was placed against it in the Apps tab basically advising not to install it.  FCP if installed should also complain if the plugin is installed.  Because the author @dorgan is actively trying to fix these problems, it has not as of yet been blacklisted and completely banned from being installed, but that is the next step should his attempts falter or the plugin is abandoned altogether.  

 

It is not advised to have this plugin installed currently, and all current installations should immediately be removed until further notice.

[dorgan]

Once problems became apparent with the network stats plugin (Oct 7th), a mod comment was placed against it in the Apps tab basically advising not to install it.  FCP if installed should also complain if the plugin is installed.  Because the author [mention=78375]dorgan[/mention] is actively trying to fix these problems, it has not as of yet been blacklisted and completely banned from being installed, but that is the next step should his attempts falter or the plugin is abandoned altogether.  
 
It is not advised to have this plugin installed currently, and all current installations should immediately be removed until further notice.

I am working on the issues called out in plugin support thread however I has been stated by several people that they do not believe it is my plugin causing the issues noted in this thread.

[limetech]

7 minutes ago, dorgan said:

I am working on the issues called out in plugin support thread however I has been stated by several people that they do not believe it is my plugin causing the issues noted in this thread.

It appears that something is creating the path '/mnt/user/xxx' before system has fully initialized.  Plugins install very early in startup, if some plugin startup code did something like 'mkdir -p /mnt/user' or 'mkdir -p /mnt/user/<any path>' we would see error messages in syslog similar to what we see.  Won't know for sure if this is the issue but big clue if OP reports back.

[pluginCop]

It will definitely prevent the array from stopping because it continually writes to a file stored on the array

It will also give weird results because at startup after a reboot (clean or otherwise), because it writes to /mnt/user which doesn't exist until after the array is started which is way after the plugin installs.

Anecdotally, it is implicated in a few cases of /mnt/user being dropped completely.  

Switching the plugin to instead utilize RAM and forgetting about history between boots may solve everything.

[dorgan]

It will definitely prevent the array from stopping because it continually writes to a file stored on the array

It will also give weird results because at startup after a reboot (clean or otherwise), because it writes to /mnt/user which doesn't exist until after the array is started which is way after the plugin installs.

Anecdotally, it is implicated in a few cases of /mnt/user being dropped completely.  

Switching the plugin to instead utilize RAM and forgetting about history between boots may solve everything.

Excellent, thank you for pointing this out. This helps in coming up with a fix on this. I appreciate this. I will add event scripts for array start and stop and not create the location inside /mnt/user/ until after the array has started.

[limetech]

5 hours ago, dorgan said:

I will add event scripts for array start and stop and not create the location inside /mnt/user/ until after the array has started.

That's the proper solution except you probably want to use 'disks_mounted' and 'unmounting_disks' events.

[dorgan]

Alright I just release a new version that reverts to using the default database path (/var/lib/vnstat), that will not be persistent across reboots.  This should remove my "bad mark" as well as fix any problems people with having with array shares not being visible or stopping array from stopping.  I will work on another version that will listen for the events and utilize those to copy the db in/out of memory.

[Defiant1]

I had the same issue, and the update to networkstats plugin fixed it. I just want to say thank you for fixing it fast.