• (6.8.0 RC3)Remote NFS Shares disappearing/dying randomly

    drawmonster

    By drawmonster

      • Retest Minor

    Been using NFS remote shares between my various Unraid servers for a couple years. With the latest RC, the shares stay mounted in the GUI, but disappear from the other servers. In the GUI they also show up as "0 B". This seems to happen randomly from what I can see. Or maybe there's a new time out I don't know about? I'm getting lots of these entries in my system logs: 

    Oct 20 13:06:07 Unraid2 kernel: NFS: server 192.168.1.227 error: fileid changed
Oct 20 13:06:07 Unraid2 kernel: fsid 0:46: expected fileid 0x10000400999c2, got 0x2000180000062
Oct 20 13:06:07 Unraid2 kernel: NFS: server 192.168.1.227 error: fileid changed
Oct 20 13:06:07 Unraid2 kernel: fsid 0:46: expected fileid 0x10000400999c2, got 0x2000180000062
Oct 20 13:06:11 Unraid2 kernel: NFS: server 192.168.1.227 error: fileid changed
Oct 20 13:06:11 Unraid2 kernel: fsid 0:46: expected fileid 0x10000400999c2, got 0x2000180000062
Oct 20 13:06:11 Unraid2 kernel: NFS: server 192.168.1.227 error: fileid changed
Oct 20 13:06:11 Unraid2 kernel: fsid 0:46: expected fileid 0x10000400999c2, got 0x2000180000062
Oct 20 13:06:17 Unraid2 kernel: NFS: server 192.168.1.227 error: fileid changed
Oct 20 13:06:17 Unraid2 kernel: fsid 0:46: expected fileid 0x10000400999c2, got 0x2000180000062
Oct 20 13:06:17 Unraid2 kernel: NFS: server 192.168.1.227 error: fileid changed
Oct 20 13:06:17 Unraid2 kernel: fsid 0:46: expected fileid 0x10000400999c2, got 0x2000180000062
Oct 20 13:07:20 Unraid2 kernel: NFS: server 192.168.1.227 error: fileid changed
Oct 20 13:07:20 Unraid2 kernel: fsid 0:46: expected fileid 0x10000400999c2, got 0x2000180000062
Oct 20 13:07:20 Unraid2 kernel: NFS: server 192.168.1.227 error: fileid changed
Oct 20 13:07:20 Unraid2 kernel: fsid 0:46: expected fileid 0x10000400999c2, got 0x2000180000062

    I'm playing whack a mole. I have to stop my array to unmount the problem NFS shares. Then I can re-add them and they work for a time, but then do the same thing randomly.

    74e08J6yPA.png

    unraid2-diagnostics-20191020-1812.zip

    Go to reports Prereleases

    User Feedback

    Recommended Comments

    drawmonster

    The remote NFS shares are only accessed by another Unraid server. Mounted and used by a few containers. That's how I know when they go down. The container starts spitting errors and file progress stops.

    Link to comment
    frozenpine

    I have found when this happens restarting the container that uses the share is all that is needed. If you have more than container using shares restart them one at time until the errors stop.

     

    'GUI they also show up as "0 B"' this might be a GUI issue. I see shares NFS and SMB listed like this frequently not new to 6.8. Refreshing the page normally cleans it up, maybe there is a timeout on reading this data so 0 is displayed so the page doesn't hang.

    Link to comment
    drawmonster

    Yeah, that and mounting/umounting the shares seems to fix them temporarily. Just annoying when trying to process 20k files with a container and it keeps dying half way through due to shares disappearing. Which means that all the progress is loss.

     

    I'm most likely going to take both servers back to 6.6.7. Having this issue with 6.8, and have terrible performance and iowait in 6.7.

    Link to comment
    limetech

    From the logs it looks like that file was moved from one disk/cache to another and still be accessed via NFS user share export.  What should happen is 'stale file handle' and NFS client should LOOKUP the file by path again - why this doesn't happen is what I have to look into.  Umount/remount the NFS share should work as well.

     

    The source of this issue is that NFS is an archaic protocol that relies on unchanging numeric "file handles" (instead of being path based like SMB).  This makes NFS both insecure and difficult to manage with stacking and/or clustering file systems.  AFP has the same issue and no doubt this was a major reason Apple decided they needed to dump it.  My suggestion is to dump NFS.

     

    Edit: you can also avoid this problem by turning off hard link support in Settings/Global Share Settings, but then you lose hard link support.

    Link to comment
    frozenpine

    Thanks, I might not need hard links. As for SMB as a replacement, I switch from it to NFS because temporarily losing shares would leave unraid in state that would require unclean shutdown. Maybe all that has been fixed in 6.8 :>)

    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.