ZEBaker98 Posted October 9, 2018 Share Posted October 9, 2018 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 Link to comment
limetech Posted October 9, 2018 Share Posted October 9, 2018 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. Link to comment
pluginCop Posted October 10, 2018 Share Posted October 10, 2018 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. Link to comment
dorgan Posted October 10, 2018 Share Posted October 10, 2018 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. Link to comment
limetech Posted October 10, 2018 Share Posted October 10, 2018 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. Link to comment
pluginCop Posted October 10, 2018 Share Posted October 10, 2018 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. Link to comment
dorgan Posted October 10, 2018 Share Posted October 10, 2018 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. Link to comment
limetech Posted October 10, 2018 Share Posted October 10, 2018 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. Link to comment
dorgan Posted October 10, 2018 Share Posted October 10, 2018 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. Link to comment
Defiant1 Posted October 12, 2018 Share Posted October 12, 2018 I had the same issue, and the update to networkstats plugin fixed it. I just want to say thank you for fixing it fast. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.