Jump to content

  • 6.12 rc6 - Exclusive Shares Not Compatible with NFSv4.

    XtremeOwnage

    By XtremeOwnage

      • Solved Minor

    This was emailed in as well. #25089

     

    From the remote host-


    root@kube01:~# mount -t nfs4 -o nfsvers=4.0,actimeo=1,soft,timeo=300,retry=2 10.100.5.2:/mnt/user/longhorn-backups test/ mount.nfs4: mounting 10.100.5.2:/mnt/user/longhorn-backups failed, reason given by server: No such file or directory

     

    From Unraid
    root@Tower:/mnt/user# cat /etc/exports

    ...

    "/mnt/user/longhorn-backups" -fsid=105,async,no_subtree_check 10.100.5.0/24(sec=sys,rw,insecure,anongid=100,anonuid=99,all_squash)

    ...

    root@Tower:/mnt/user# ls -al /mnt/user 

    longhorn-backups -> /mnt/main/longhorn-backups/ 


    NFS Shares:

    root@Tower:/mnt/main/home/root# ./showNfsClients
    v3 clients: (via /var/lib/nfs/rmtab)
    10.100.5.100:/mnt/main/photos:0x00000001
    10.100.5.105:/mnt/main/nextcloud:0x00000001
    10.100.5.105:/mnt/cache/scanned:0x00000001
    10.100.5.105:/mnt/main/documents:0x00000001


    v4 clients: (via /proc/fs/nfsd/clients)
    address: "10.100.5.100:798"
    name: "Linux NFSv4.2 longhorn-manager-j2wk7"
    address: "10.100.5.106:847"
    name: "Linux NFSv4.0 longhorn-manager-hgtt8/10.100.5.2"
    address: "10.100.5.105:681"
    name: "Linux NFSv4.2 instance-manager-r-23866f720a1af5bf2236875845f4f132"
    address: "10.100.5.105:701"
    name: "Linux NFSv4.2 longhorn-manager-7txwq"
    address: "10.100.5.106:909"
    name: "Linux NFSv4.2 instance-manager-r-9613737d8c4e4685af4dda69f50a4f50"
    address: "10.100.5.100:659"
    name: "Linux NFSv4.2 instance-manager-r-ce2be797b831f1d30f228947e0bec7a3"




    To note, this ONLY impacts the following conditions:

     

    1. Remote client is using NFSv4, instead of NFSv3.

    2. Share, is "Exclusive share" added in rc6.

    3. ZFS may, or may not be a factor here. 

     

     

    I do believe this issue is due to nfsv4 not liking the symlink. 

    Adding a secondary storage, converting back to a FUSE/SHFS mount, addresses issue.

     

    • Thanks 1
    Go to reports Prereleases

    User Feedback

    Recommended Comments

    XtremeOwnage
    12 hours ago, dlandon said:

    Try putting a trailing slash on the mount directory: /mnt/user/longhorn-backups/.

    Did not help / change the issue.

    Link to comment
    dlandon

    I just ran a test and it worked for me.  Your path needs to be the actual share path.  The exclusive share may not be in /mnt/user/.  For example you have this as an exclusive share on a pool.  Your mapping should be '/mnt/pool/longhorn-backups/.

    Link to comment
    XtremeOwnage

    The ls -al output is in the top post.
     

    Quote

    root@Tower:/mnt/user# ls -al /mnt/user 

    longhorn-backups -> /mnt/main/longhorn-backups/ 

     

     

     


     

    Link to comment
    XtremeOwnage

    To reproduce this issue-

    Create a new share. Just make sure the primary storage is a pool.
    image.thumb.png.ac394d8153c2438393536cacb24909d1.png

     

    Enable NFS.

    image.png.7c06b55628fd1a06adf2b49901cf2d2b.png

    From another host, connect to it, using nfsv3.

    image.png.c1c2df49875658002e117af23f7f53c9.png

    Notice, it works.

    image.png.97712d8e2926731586d8f8696e78072d.png

    Now, mount it using nfs v4.

    image.thumb.png.d46cb3273e92d1bf295c03c5e37e5368.png

     

     

    Notice it does NOT work.

    Modify the share to add a secondary storage (removing exclusive access).


    image.thumb.png.0d9908e17ccf08eddd110c2a3248ee96.png

    Mount it again.

    image.thumb.png.892e3b8a21482de97756eaf651521d22.png

    Works fine.

    Link to comment
    dlandon

    I did a little experiment and to mount the NFS share, you need to mount /mnt/cache/dummyshare/ and not /mnt/user/dummyshare/.

    Link to comment
    XtremeOwnage

    Logically- that makes sense. However, unraid doesn't export /mnt/cache.

    image.thumb.png.f5127a7ca92bcfa32d82fd5035c348ef.png

    /etc/exports.
    image.thumb.png.0637d530285c61a179f2bc033f874c2d.png

     

     

     

    You ARE testing this using 6.12, RC6 with exclusive shares enabled, right?

    Link to comment
    dlandon
    13 minutes ago, XtremeOwnage said:

    You ARE testing this using 6.12, RC6 with exclusive shares enabled, right?

    Yes, and it works for me.

    Screenshot 2023-05-19 104519.pngScreenshot 2023-05-19 104548.png

     

    root@BackupServer:~# ls -la /mnt/cache/
    total 4
    drwxrwxrwx  5 nobody users   50 May 18 17:47 ./
    drwxr-xr-x 13 root   root   260 May 19 10:45 ../
    drwxrwxrwx  3 nobody users 4096 May 11 04:40 Syslogs/
    drwxrwxrwx  3 nobody users   32 Apr  4 13:42 Unraid/
    drwxrwxrwx  7 nobody users  105 Apr 28 18:40 appdata/

     

    And the UD mount to mount the share: 

    May 19 10:49:04 MediaServer unassigned.devices: Mounting Remote Share 'BACKUPSERVER:/mnt/cache/Syslogs'...
May 19 10:49:04 MediaServer unassigned.devices: Mount NFS command: /sbin/mount -t 'nfs4' -o rw,noacl 'BACKUPSERVER:/mnt/cache/Syslogs/' '/mnt/remotes/BACKUPSERVER_Syslogs'

     

    Link to comment
    XtremeOwnage

    I am not using unassigned devices to mount this.
     

    I am using the built-in functionality as of 6.12, in the form of adding zfs pools, and as of rc6, exclusive shares.

    This ticket, is not due to me needing a work-around, this ticket, is due to me reporting a bug introduced in the current rc6, where an exclusive pool-based share, will no longer function when accessed by a NFSv4 client. 

    I am testing the built-in functionality, and not third party plugins / apps.

    Link to comment
    dlandon

    I only gave you that UD mount as an example of what works.

     

    My example is the same as yours, with the exception that my share on a XFS formatted cache disk, and I use the server name instead of the IP address in the mount command.  Maybe one of those affects the mount in your case.

     

    Please post your diagnostics so I can have a better look.

    Link to comment
    dlandon

    Why are you mounting like this: 

    main/longhorn-backups    14T  130G   14T   1% /mnt/main/longhorn-backups

     

    That will be a problem.

     

    Your dummy share is at /mnt/cache/: 

    cache/dummyshare        1.7T  128K  1.7T   1% /mnt/cache/dummyshare

     

    So your should be able to access it.

    Link to comment
    XtremeOwnage

    This odd thing just happened.

    I rebooted the server due to having mover logging enabled earlier- causing diagnostics to crash when trying to generate a zip file.

    After... rebooting...

    root@kube01:~# mount -t nfs4 10.100.5.2:/mnt/cache/dummyshare test/
    root@kube01:~/test# touch hi
    root@kube01:~/test# touch it works?

     

    root@Tower:/mnt/user/dummyshare# ls
    hi  it  works?

    cat /etc/exports

    "/mnt/user/dummyshare" -fsid=114,async,no_subtree_check *(rw,sec=sys,insecure,anongid=100,anonuid=99,all_squash)

     

    Relevant entries under /mnt/user

    image.png.08614fe062189b75ee16839f86704c64.png

     

    image.png.253ca3ddcc948b62b105bde82e2d8e0a.png

    Seems your earlier note of mounting the direct path, appears to work now, after rebooting... oddly.

    Wonder, why this didn't work before

    Mounting directly to /mnt/user doesn't work though.

     

     

     

     

    Could be slightly confusing to some users. Especially, if they add a secondary storage, and the NFS mount then breaks.

     

    Edit- Cleaned up non-relevant data.

     

     

     

     

     

    Edited by XtremeOwnage
    Link to comment
    dlandon

    Ah, it's the old reboot fix.  Funny how that clears up a lot of stuff sometimes.

     

    We re looking at the options.  The /mnt/user/share should work.  I'll leave this open and see if we can implement a fix for this.  You could then test it.

    Link to comment
    XtremeOwnage

    I wouldn't have thought to reboot- especially, since I just rebooted it yesterday! But, hey...

    Regarding testing- please do let me know. I would be happy to help test anything regarding the new ZFS implementations/rollouts. 

    Have already tested zpool expansions, and they worked fantastically well. Looking forward to seeing zfs-native encryption, ability to manage zfs snapshots via gui, and even potentially the ability to spin up zvols for VMs, instead of .img files on disk. (zvols do work with VMs, just need to pass /dev/zvol/..., but, this is all done via CLI)

    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.

×
×
  • Create New...