October 9, 20187 yr 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, 20187 yr by ZEBaker98 removed html formatting
October 9, 20187 yr 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.
October 10, 20187 yr 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.
October 10, 20187 yr 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.
October 10, 20187 yr 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.
October 10, 20187 yr 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.
October 10, 20187 yr 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.
October 10, 20187 yr 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.
October 10, 20187 yr 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.
October 12, 20187 yr I had the same issue, and the update to networkstats plugin fixed it. I just want to say thank you for fixing it fast.
Archived
This topic is now archived and is closed to further replies.