• After upgrade from v6.8.3 to v6.9.0-beta22 SMB-Shares disappear at reboot (random)


    DarkMan83
    • Minor

    Hi there,

     

    i upgraded from Unraid v6.8.3 to v6.9.0-beta22 for testing.

     

    After that upgrade all my Shares disappeard in GUI under Shares.

    In the Server log i get errors like:

    emhttpd: error: get_filesystem_status, 6475: Operation not supported (95): getxattr: /mnt/user/...

    Those errors appear also for new Shares, never created before.

    I have no custom mounts under "/usr/mnt" and i have not modified any files.

     

    I can get it working again, if i create a share with the same name as before and than reboot. After that all shares are back again.

    But if i reboot several times they disappear again and i have to redo this procedure again.

     

    The SMBD log has no errors or stacktraces.

     

    Currently i have it working, but it could go to the "no shares" state again on reboot.

     

    If this happens again, i will provide a diagnostics.zip here...

     

    Greetings

    Dark

    thebeast-diagnostics-20200706-2101-shares-visible.zip

    • Like 1



    User Feedback

    Recommended Comments

    Quote

    I have no custom mounts under "/usr/mnt" and i have not modified any files.

    Perhaps this is a typo, but /usr/mnt doesn't exist normally, and has nothing to do with user shares.

     

    Quote

    If this happens again, i will provide a diagnostics.zip here...

    Not really a useful report without them:

     

    https://forums.unraid.net/bug-reports/prereleases/how-to-install-prereleases-and-report-bugs-r8/

     

    Quote

    Reporting Bugs:

    Please only report bugs/issues that are unique to the prerelease.

    Important: if possible, please include information that describes how to reproduce the bug/issue.

    Please visit Tools/Diagnostics and attach the diagnostics.zip file to your post.

     

    And your symptoms suggest other problems that wouldn't be related to any specific release.

    Link to comment
    Quote

    In the Server log i get errors like:

    I don't see that message in your logs but there are other messages that shouldn't ordinarily be there.

    When it gets into a "no shares state" please capture and post diagnostics captured at that time.  thx

    Link to comment

    I see you edited the first post and put diagnostics there. It is OK to do that, but make sure you make a new post with any new content such as diagnostics, so they won't be overlooked. We have no way to know when you edit a previous post without looking back at old posts.

    Link to comment

    I can confirm this issue (or at least a related one), though mine really has nothing to do with SMB itself. Today, my locally-mounted "shares" disappeared completely. Here's the blow-by-blow:

     

    While accessing a previously running container (Grafana), I was getting errors in the browser. Stopping and starting the container resulted in the error "Execution error - server error". Then I realized that all of my Docker containers weren't working.

     

    Attempting to restart Docker itself, I noticed this:

     

    ApplicationFrameHost_MhHvKN2CYT.thumb.jpg.02d080ce11e7b35ef9f7f5aeb2333a2a.jpg

     

    And, sure enough, navigating to "Shares" in the GUI, I don't have any mounted shares:

     

    ApplicationFrameHost_W2ywPWbqGO.thumb.jpg.7afc823dd5c470bc71cf92dcf74af6ed.jpg

     

    The only thing that looks interesting in the syslog is this, which occurred at the time I see my server going offline in Grafana:

     

    shfs: shfs: ../lib/fuse.c:1451: unlink_node: Assertion `node->nlookup > 1' failed.

    Research:

     

    This looks similar to a problem reported last year with the same error message and symptoms:

     

     

    Let me know if you would like for me to open up a new issue.

     

    -TorqueWrench

    Edited by T0rqueWr3nch
    Link to comment
    8 minutes ago, T0rqueWr3nch said:

    This looks similar to a problem reported last year with the same error message and symptoms:

    Yes, this is an old issue, not related to this release, it appears to be a fuse issue that happens when a file is removed and then moved, I believe it happens mostly when using for example a media processing docker.

    • Like 1
    Link to comment

    Maybe it's old, maybe it's not.

    I've also found that one topic, but i never had those issues before.

    On v6.8.3 all was fine and all shares worked like they should, no matter how many reboot's i've done.

     

    This only appeared after upgrading to v6.9.0-beta22 the first time and continues to reoccur after reboots randomly and than doesn't go away by simply rebooting.

     

    For the "/usr/mnt/" jipp, that is a typo, for sure it should name "/mnt/usr/...".

    Today i restared the server 2 times, but as this SMB thing is random, you my know it, the shares working so far.

     

    I'll report back, if this changes the next time.

     

    P.S. Edit of the first Post in the first 5 mins shouldn't be a problem at all. I see no Point in "not adding the Attachement" to the first post.

     

    Greetings

    Dark

    Link to comment

    Same. I've never had this issue before, though admittedly it could just be a coincidence.

     

    Just to confirm @DarkMan83, since I don't think this is necessarily an "SMB" issue, when you navigate to "Shares" in the GUI, are your shares missing there as well? In my case the locally-mounted "shares" themselves were gone. My working theory is that this is what's going on for most of the "SMB issues" being reported. I think for many users, they only interact with unRAID via using its exported SMB shares and so the issue manifests itself as an "SMB problem" though the underlying cause is that the local mounts themselves are gone. Just my theory so far.

     

    Regardless, the flag on this post seems misprioritized. It doesn't seem like a "minor" issue.

     

    -TorqueWrench

    Edited by T0rqueWr3nch
    Link to comment
    38 minutes ago, T0rqueWr3nch said:

    shfs: shfs: ../lib/fuse.c:1451: unlink_node: Assertion `node->nlookup > 1' failed.

    It's very easy to confirm if it's this same issue, the line above always appears when the shares go away.

    Link to comment
    45 minutes ago, DarkMan83 said:

    for sure it should name "/mnt/usr/..."

    Just so nobody gets confused. The user shares are at /mnt/user

    Link to comment
    23 hours ago, trurl said:

    symptoms suggest other problems that wouldn't be related to any specific release.

    Other reasons people seem to lose user shares include unmountable disks and incorrect permissions on /mnt/user

    Link to comment
    1 hour ago, T0rqueWr3nch said:

    The only thing that looks interesting in the syslog is this, which occurred at the time I see my server going offline in Grafana:

     

    
    shfs: shfs: ../lib/fuse.c:1451: unlink_node: Assertion `node->nlookup > 1' failed.

    Hitting this assertion will kill the fuse process and lead to the other errors.  This might be very difficult to track down.

    Do you have NFS enabled?  If so, and you don't need it, try disabling NFS.  Settings/NFS

    Link to comment
    On 7/7/2020 at 7:20 PM, T0rqueWr3nch said:

    Same. I've never had this issue before, though admittedly it could just be a coincidence.

     

    Just to confirm @DarkMan83, since I don't think this is necessarily an "SMB" issue, when you navigate to "Shares" in the GUI, are your shares missing there as well? In my case the locally-mounted "shares" themselves were gone. My working theory is that this is what's going on for most of the "SMB issues" being reported. I think for many users, they only interact with unRAID via using its exported SMB shares and so the issue manifests itself as an "SMB problem" though the underlying cause is that the local mounts themselves are gone. Just my theory so far.

     

    Regardless, the flag on this post seems misprioritized. It doesn't seem like a "minor" issue.

     

    -TorqueWrench

    Of course i lose all those shares in the GUI.

    Link to comment
    On 7/7/2020 at 8:07 PM, trurl said:

    Other reasons people seem to lose user shares include unmountable disks and incorrect permissions on /mnt/user

    I already checked the permissions and they're ok. Why shouldn't they? I've nothing changed on those files upgrading to v6.9.0-beta22.

    Edited by DarkMan83
    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.