mount NFSv4 alias via SmartConnect Zone name fails with mount.nfs: Operation not permitted.

Summary: mount NFSv4 alias via SmartConnect fully qualified domain name fails with mount.nfs: Operation not permitted.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

In corner case, mount NFSv4 alias via SmartConnect fully qualified domain name(FQDN) fails with "mount.nfs: Operation not permitted". 
There is no such issue for NFSv4 clients mount NFS export full data path.
There is no such issue for NFSv4 Kerberos clients mount nfs exports with kerberos Security Type (krb5 | krb5i | krb5p).
There is no such issue for NFSv3 clients.

Here is an example in lab repro:

  • The nfs client kerberosed with a valid gss ticket.
  • Create unix only flavor NFS export and create a NFS alias to the data path.
  • Use the gss client mount with NFSv4 via FQDN:Alias
tcr-1# isi nfs settings global view
NFS Service Enabled: Yes
      NFSv3 Enabled: Yes
        NFSv3 RDMA Enabled: No
      NFSv4 Enabled: Yes
              v4.0 Enabled: Yes
              v4.1 Enabled: No
              v4.2 Enabled: No
     Rquota Enabled: No
 
tcr-1# isi nfs aliases list
Zone   Name       Path
----------------------------------
System /aliases01 /ifs/data/pod-db
----------------------------------
Total: 1
 
tcr-1# isi nfs exports view 5
                     ID: 5
                   Zone: System
                  Paths: /ifs/data/pod-db
            Description:
                Clients: -
           Root Clients: -
      Read Only Clients: -
     Read Write Clients: -
               All Dirs: No
             Block Size: 8.00k
           Can Set Time: Yes
       Case Insensitive: No
        Case Preserving: Yes
       Chown Restricted: No
    Commit Asynchronous: No
Directory Transfer Size: 128.00k
               Encoding: DEFAULT
               Link Max: 32767
         Map Lookup UID: No
              Map Retry: Yes
               Map Root
                    Enabled: False
                       User: nobody
              Primary Group: -
           Secondary Groups: -
           Map Non Root
                    Enabled: False
                       User: nobody
              Primary Group: -
           Secondary Groups: -
            Map Failure
                    Enabled: False
                       User: nobody
              Primary Group: -
           Secondary Groups: -
               Map Full: Yes
          Max File Size: 8192.00P
          Name Max Size: 255
            No Truncate: No
              Read Only: No
            Readdirplus: Yes
   Readdirplus Prefetch: 10
  Return 32Bit File IDs: No
 Read Transfer Max Size: 1.00M
 Read Transfer Multiple: 512
     Read Transfer Size: 128.00k
          Security Type: unix
   Setattr Asynchronous: No
               Snapshot: -
               Symlinks: Yes
             Time Delta: 1.0 ns
  Write Datasync Action: datasync
   Write Datasync Reply: datasync
  Write Filesync Action: filesync
   Write Filesync Reply: filesync
  Write Unstable Action: unstable
   Write Unstable Reply: unstable
Write Transfer Max Size: 1.00M
Write Transfer Multiple: 512
    Write Transfer Size: 512.00k

Mount NFS alias via SC zone(FQDN) fails with "Operation not permitted":
[root@centos8test ~] mount -t nfs -o vers=4 tcr-nfs.gz.local:/aliases01  /mnt/test -vvvv
mount.nfs: timeout set for Wed Apr 10 10:19:32 2024
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.64,clientaddr=192.168.1.41'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.1.64,clientaddr=192.168.1.41'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,addr=192.168.1.64,clientaddr=192.168.1.41'
mount.nfs: mount(2): Operation not permitted
mount.nfs: Operation not permitted
Mount the same NFS export full data path works: 
[root@centos8test ~]# mount -t nfs -o vers=4 tcr-nfs.gz.local:/ifs/data/pod-db  /mnt/test -vvvv
mount.nfs: timeout set for Wed Apr 10 10:23:46 2024
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.66,clientaddr=192.168.1.41'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.1.66,clientaddr=192.168.1.41'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,addr=192.168.1.66,clientaddr=192.168.1.41'

[root@centos8test ~]# nfsstat -m
/mnt/test from tcr-nfs.gz.local:/ifs/data/pod-db
 Flags: rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.41,local_lock=none,addr=192.168.1.66

Cause

From the network trace captured, PowerScale OneFS nodes reply no values to SECINFO call, but actually target export has UNIX_AUTH flavor. 
 
$ tshark -r nfsv4-gss.pcap -Y frame.number==196 -O nfs
Frame 196: 194 bytes on wire (1552 bits), 194 bytes captured (1552 bits)
Ethernet II, Src: VMware_9b:17:92 (00:50:56:9b:17:92), Dst: VMware_9b:f4:2b (00:50:56:9b:f4:2b)
Internet Protocol Version 4, Src: 192.168.1.64, Dst: 192.168.1.41
Transmission Control Protocol, Src Port: 2049, Dst Port: 960, Seq: 2493, Ack: 3217, Len: 128
Remote Procedure Call, Type:Reply XID:0xc95e46e7
Network File System
    [Program Version: 4]
    [V4 Procedure: COMPOUND (1)]
    GSS Data, Ops(2): PUTFH SECINFO
        Length: 36
        GSS Sequence Number: 3
        Status: NFS4_OK (0)
        Tag: <EMPTY>
            length: 0
            contents: <EMPTY>
        Operations (count: 2)
            Opcode: PUTFH (22)
                Status: NFS4_OK (0)
            Opcode: SECINFO (33)
                Status: NFS4_OK (0)
                Flavors Info
                    no values
        [Main Opcode: SECINFO (33)]
    GSS Checksum: 0000001c040405ffffffffff000000000014cf198b8963d34b9f04f3a39b04fc
        GSS Token Length: 28
        GSS-API Generic Security Service Application Program Interface
            krb5_blob: 040405ffffffffff000000000014cf198b8963d34b9f04f3a39b04fc
                krb5_tok_id: KRB_TOKEN_CFX_GetMic (0x0404)
                krb5_cfx_flags: 0x05, AcceptorSubkey, SendByAcceptor
                    .... .1.. = AcceptorSubkey: Set
                    .... ..0. = Sealed: Not set
                    .... ...1 = SendByAcceptor: Set
                krb5_filler: ffffffffff
                krb5_cfx_seq: 1363737
                krb5_sgn_cksum: 8b8963d34b9f04f3a39b04fc
There is NFS defect PSCALE-219044 found in this nfsv4 Alias mount scenario.

Resolution

Engineering is working on the root cause and make sure the fix should fix all the scenarios.

There is no workaround on PowerScale OneFS Isilon-side yet, to workaround this issue, please manually add "sys" mount option on client-side.
Article Properties
Article Number: 000224305
Article Type: Solution
Last Modified: 23 May 2024
Version:  2
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.