ONTAP NFS Access Denied or Mount Hangs: Complete Stored Troubleshooting Workflow

This translates the stored ONTAP 9 NFS access-denied/mount-hang workflow. Its same-name official English KB was found; the current public page exposes the overview/common causes, while this stored source contains a longer historical procedure. Keep the applicable release’s commands and support guidance in view. Diagnostic cache operations can affect live lookups; collect the relevant command/output evidence and scope any approved corrective action to the real SVM, node, policy and client.

Common causes to distinguish

No export rule matches the client IP/hostname.
A mount attempted before provisioning DNS/netgroups left a negative access-cache entry.
Reverse resolution does not match the hostname or netgroup in the export rule.
DNS search-domain configuration or PTR records are missing/wrong.
DNS, NIS or LDAP lookups time out or cannot reach their configured servers.
An export hostname is incorrectly formed or the intended fully qualified/rooted name is wrong. A rooted DNS name ends in a dot; it does not mean the UNIX root username.
Routing or firewall policy blocks required name-service communication.
NIS/LDAP lacks the needed netgroup.byhost mapping, or netgroup hostnames do not resolve.
Netgroup hostname matching differs by lookup source/method/case.
NFSv4 or NFSv3 AUTH_NULL traversal encounters an NTFS security-style path requiring the applicable identity mapping. This is not a universal claim that all NFS identity mapping is limited to NTFS.

1. Confirm the service and evaluate the complete export path

Cluster1::> vserver nfs show

Virtual  General
Server   Access  v3     v4.0    v4.1    UDP    TCP
-------- ------- -------- -------- -------- -------- --------
svm1   true   enabled  enabled  disabled enabled  enabled
svm2   true   enabled  disabled disabled enabled  enabled

The source examples show two SVMs with different NFSv4 availability. Verify the client’s actual protocol, authentication and requested access, then test the intended volume:

Cluster1::> vserver export-policy check-access -vserver <vserver> -volume <volume> -client-ip <clientIP> -auth <auth_type> -proto <proto> -access-type <type>

2. When export-policy check-access succeeds

A successful check-access result describes export-policy evaluation, not every filesystem permission or transport check. Inspect the relevant access-cache entry with the historical diagnostic command:

Cluster1::> nblade access-cache show -node <node> -vserver <vserver> -policy <policy> -address <address>

If a stale negative entry is confirmed, the source flushes that exact scope and retries:

Cluster1::> nblade access-cache flush -vserver <vserver> -node <node> -policy <policy> -address <clientIP>

If check-access succeeds but the mount still fails while using NFSv4 or NFSv3 auth_null, inspect traversal and identity mapping. The source’s truncated mount example is corrected as a placeholder command:

mount <FILER_IP>:/ <MOUNT_POINT>

If mounting the SVM root succeeds, use cd directory by directory to find the first denied path; record it. Inspect its security style and permissions:

Cluster1::> vserver security file-directory show -vserver <vserver> -path <path>

For NTFS-style paths, determine the user mapping/identity using the applicable supported credential-inspection procedure, then correlate the resulting user with the actual ACL:

Cluster1::*> secd authentication show-creds -node <node> -vserver <vserver> -uid <clientUID>

Cluster1::> vserver security file-directory show -vserver <vserver> -path <path>

For UNIX-style paths, check the client UID/GIDs and traversal/read/write permissions:

Cluster1::> vserver security file-directory show -vserver <vserver> -path <path>

For root, inspect the export rule’s superuser handling instead of assuming root always bypasses export or file permissions:

Cluster1::> vserver export-policy rule show -vserver <vserver> -policyname <policy name>

For NFSv4, verify the actual ID-mapping configuration. If a newly created junction is hidden behind a configured load-sharing root mirror, check whether the ls-mirror-set is current. The source illustrates updating the intended root LS set:

Cluster1::> snapmirror update-ls-set -source-path cm2244a-cn://vs_cifs/vs2_root

Its cluster/SVM/root-volume name is a historical example, not a target to copy. LS updates apply only when that architecture is actually configured.

3. When check-access denies the client

Inspect the relevant event log show name-service events and the policy/rule that denied access:

Cluster1::> event log show -message-name *nis*,*dns*,*ldap*

Cluster1::> vserver export-policy rule show -vserver <vserver> -policyname <policy name>

If a required rule is absent, create only the intended access rule through the supported configuration procedure. If one exists, check the client-match type:

IP/subnet: confirm that the actual client address is included in the mask. 0.0.0.0/0 means all IPv4 clients; it is an explanation of syntax, not a recommendation to broaden access.
Hostname: verify forward resolution and the exact fully qualified name.
DNS domain: the source uses a leading dot for a domain client-match; validate the intended rule syntax.

Cluster::*> vserver services name-service getxxbyyy gethostbyname -node <node> -vserver <vserver> -hostname <HOST_NAME>

Check reverse/PTR resolution as well:

Cluster::> vserver services name-service getxxbyyy gethostbyaddr -node <node> -vserver <vserver> -ipaddress <clientip>

4. Diagnose netgroup membership and caches

Check the SVM name-service switch order:

Cluster::> ns-switch show -vserver <vserver> -database netgroup

If LDAP supplies netgroups, inspect whether netgroup.byhost is enabled in the correct client configuration:

Cluster::> ldap client show -client-config jason.local -fields is-netgroup-byhost-enabled

For a source using netgroup.byhost, perform the corresponding by-host lookup; netgroup.byhost is not the same search as expanding a netgroup:

Cluster::> getxxbyyy netgrpbyhost -node <node> -vserver <vserver> -netgroup <netgroup> -clientIP <CLIENT_IP>

For LDAP without netgroup.byhost, the source instead tests membership using netgrp:

Cluster::>getxxbyyy netgrp -node <node> -vserver <vserver> -netgroup <netgroup> -client <ip>

If the client is found but access remains stale after the underlying data is corrected, the source clears the relevant netgroup cache and repeats check-access:

Cluster::>export-policy cache flush -vserver <vserver> -cache netgroup

If getxxbyyy does not find the client, verify reverse resolution and compare the returned hostname against the intended netgroup entry:

Cluster::>getxxbyyy gethostbyaddr -node <node> -vserver <vserver> -ipaddress <clientip>

With netgroup.byhost, match the expected hostname/key and case. Other sources/methods have their own case behavior; the source’s contradictory “case-sensitive but” sentence is not a universal rule. Inspect the actual response and use consistent canonical names.

Correct a missing/misspelled hostname or update the current local netgroup file as appropriate, then invalidate only the intended caches and retest:

export-policy cache flush -vserver <VSERVER> -cache netgroup

Cluster::>nblade access-cache flush -vserver <vserver> -node <node> -policy <policy> -address <clientIP>

The source also lists these internal SecD cache-clear examples at diagnostic privilege:

Cluster1::*>secd cache clear -node <node> -vserver <vserver> -cache-name netgroup-ip

Cluster1::*>secd cache clear -node <node> -vserver <vserver> -cache-name netgroup-host

Its final line has an unverified, space-separated cache-name value. It is retained solely as an archived source excerpt, not an executable recipe; obtain the exact release-supported cache name and syntax from support:

Cluster1::*>secd cache clear -node <node> -vserver <vserver> -cache-name ldap netgroupname-to-member

Use supported export-policy cache management where applicable. Do not flush every SVM/node or change name-service order merely because this document contains an example.

5. Name-service troubleshooting sequence

For DNS, NIS and LDAP, verify the SVM/client configuration, the authoritative server’s actual entries and network reachability from the selected LIF. The source mixes admin, advanced and internal diagnostic aliases; availability varies by release. Current event definitions are inspected with event catalog show; the old event route show examples below are corrected to that documented command while their original response text is retained.

DNS configuration and response statistics

Cluster1::> vserver services name-service dns show -vserver <vserver>

Cluster1::> event log show -message-name *dns*
Cluster1::> event catalog show -message-name <EMS event name> -instance

Cluster1::> event catalog show -message-name dns.server.timed.out -instance
Message Name: dns.server.timed.out
Severity: WARNING
Corrective Action: Make sure that the DNS server is up and running and that there are no networking issues preventing the Vserver from communicating with the DNS server.
Description: This message occurs when the DNS server fails to respond to a query and timeout occurs.

For getxxbyyy gethostbyname, inspect the client’s forward A record; for getxxbyyy gethostbyaddr, inspect its PTR record. Check DNS server health, allowed queries and the actual routed source LIF.

The source uses priv advanced and historical dns info output to inspect average/minimum/maximum RTT, queries and failures. Elevated RTT can reflect server delay, loss or path latency; compare with the actual baseline:

cluster1::*> dns info

Node: node_a

          Name     Average   Minimum   Maximum    Total      Num  Host Not  Timed   Other  Format  Servfail  NotImp  Refused
Vserver   Server  RTT (us)  RTT (us)  RTT (us)  RTT (s)  Queries     Found    Out  Errors  Errors    Errors  Errors   Errors
--------  ------  --------  --------  --------  -------  -------  --------  -----  ------  ------  --------  ------  -------
my_svm     10.61.81.53    0         0         0        0        0         0      0       0       0         0       0        0
cluster    10.61.79.2   828       411      7646        0      880       878      0       0       0         0       0        0

Its ONTAP 9.0-and-later statistics example starts an external_service_op sample. Counter instances and collection syntax depend on the release; starting a sample is not itself a completed statistics report:

Cluster1::> statistics start -object external_service_op -sample-id dns_sample1

The following dns show excerpt instead displays configuration, not the completed RTT sample:

Cluster::*> dns show
                                                               Name
Vserver         State     Domains                             Servers
--------------- --------- ----------------------------------- ----------------
cluster1        enabled   demo.netapp.com                     192.168.0.253

NIS configuration and response statistics

Cluster::> nis show -vserver <vserver>

event log show -message-name *nis*
event catalog show -message-name <EMS event name> -instance

::> event catalog show -message-name nis.server.not.available -instance
Message Name: nis.server.not.available
Severity: ERROR
Corrective Action: From a UNIX (R) workstation, make sure that the NIS server is responding to requests. Also make sure that the portmapper on the NIS server is responding to requests. Make sure that there are no networking issues stopping the cluster from communicating with this NIS server.
Description: This message occurs when none of the NIS servers configured for a Storage Virtual Machine can be contacted.

Check the configured NIS servers, portmapper and the actual dynamically registered service ports. Use the same LIF/routing checks below. The source’s priv advanced / nis info example contains lookup counts, RTT, retransmits and not-found counts:

Cluster1::*> nis info
  (nis-domain)

Node: node_a

        NIS     Number of    Total   Minimum   Maximum   Average    Number of  Entry Not
Vserver Server YP Lookups  RTT (s)  RTT (us)  RTT (us)  RTT (us)  Retransmits      Found
------  ------ ----------  -------  --------  --------  --------  -----------  ---------
my_svm  10.60.252.15    0        0         0         0         0            0          0

The source says nis info is unavailable in its 9.1 context and refers to nis show. Configuration output is not a substitute for latency statistics; confirm the supported counters for the actual release.

LDAP configuration and connections

Check LDAP, correcting the source heading’s accidental reference to NIS:

Cluster1::> ldap show -vserver <vserver>
Cluster1::>ldap client show -client-config <config>

Cluster1::> event log show -message-name *ldap*
Cluster1::> event catalog show -message-name <EMS event name>

Cluster1::> event catalog show -message-name secd.ldap.noServers -instance
Message Name: secd.ldap.noServers
Severity: ERROR
Corrective Action: From a LDAP client workstation, make sure that all configured LDAP servers are responding to requests. Make sure that there are no networking issues stopping the cluster from communicating with the configured LDAP servers. Also, make sure that the portmapper running on the LDAP server is working correctly.
Description: This message occurs when none of the configured Lightweight Directory Access Protocol (LDAP) servers are accepting connections

The preserved LDAP EMS excerpt mentions portmapper, but that is not a generic LDAP requirement. Check the configured LDAP/TLS service and ports, server reachability and authentication/certificates appropriate to the deployment. Diagnostic connection statistics in the source include queue/performance and per-server RTT:

Cluster1::*>  diag secd connections show -node node2 -vserver SVM
 
[ Cache: LDAP (NIS & Name Mapping)/<no key> ]
 Queue> Waiting: 0, Max Waiting: 1, Wait Timeouts: 0, Avg Wait: 0.00ms
 Performance> Hits: 4, Misses: 1, Failures: 0, Avg Retrieval: 0.60ms
 
+ Rank: 01 - Server: 10.228.225.120 (10.228.225.120)
         Connected through the 10.63.21.9 interface, 0.0 mins ago
         Used 5 time(s), and has been available for 2 secs
         RTT in ms: mean=8.60, min=2, max=22, med=4, dev=7.58 (0.0 mins of data)

6. Manually query the configured lookup sources

The getxxbyyy family can show the selected name-service source with -show-source true. The source includes the broken literal label query. getXXbyYY; the intended family is getxxbyyy. The ns-switch ordering determines which configured source is tried. The primary command family is vserver services name-service getxxbyyy, with advanced-level access documented for current releases.

Forward lookup: getaddrinfo |gethostbyname. getaddrinfo handles the applicable address families; gethostbyname is IPv4-specific in the current guide.

cluster::*> getxxbyyy getaddrinfo -node node01 -vserver Svm -hostname support.netapp.com -show-source true
Source used for lookup: DNS
Host name: support.netapp.com
Canonical Name: support.netapp.com
IPv4: 216.240.21.18
IPv6: 2620:10a:4005:c000::a78:2d11

Reverse lookup: getnameinfo | gethostbyaddr. getnameinfo is the general counterpart; gethostbyaddr is IPv4-specific in the current guide.

cluster::*> getxxbyyy getnameinfo -node node01 -vserver Svm -ipaddress 216.240.21.18 -show-source true
Source used for lookup: DNS
IP address: 216.240.21.18
Host name: support.netapp.com

Group by ID: getgrbygid:

cluster::*> getxxbyyy getgrbygid -node node01 -vserver Svm -groupID 1000 -show-source true
Source used for lookup: Files
name: wheatley
gid: 1000
gr_mem:

Group by name: getgrbyname

cluster::*> getxxbyyy getgrbyname -node node01 -vserver Svm -groupname daemon -show-source true
Source used for lookup: Files
name: daemon
gid: 1
gr_mem:

User group list: getgrlist

cluster::*> getxxbyyy getgrlist -node node01 -vserver Svm -username root -show-source true
Source used for lookup: Unknown
pw_name: root
Groups: 0

cluster::*> getxxbyyy getgrlist -node node01 -vserver Svm -username user1 -show-source true
Source used for lookup: Files
pw_name: user1
Groups: 1000

User by name or UID: getpwbyname | getpwbyuid. The source label getpwdbyname is corrected to getpwbyname. Existing pw_passwd masking remains intact; do not publish credential/hash values from real lookup output.

cluster::*> getxxbyyy getpwbyname -node node01 -vserver Svm -username user1 -show-source true
Source used for lookup: Files
pw_name: user1
pw_passwd: *
pw_uid: 1000
pw_gid: 1000
pw_gecos:
pw_dir:
pw_shell:

cluster::*> getxxbyyy getpwbyuid -node node01 -vserver Svm -userID 60001 -show-source true
Source used for lookup: Files
pw_name: dubsquash
pw_passwd: *
pw_uid: 60001
pw_gid: 60001
pw_gecos:
pw_dir:
pw_shell:

Netgroup membership: netgrp | netgrpbyhost: uses netgroup expansion or netgroup.byhost lookup according to the method. Preserve the positive, found-by-host and not-found examples separately:

cluster::*> getxxbyyy netgrp -node node01 -vserver Svm -netgroup group1 -client myclient -show-source true
Source used for lookup: NIS
myclient is a member of group1

cluster::*> getxxbyyy netgrpbyhost -node node01 -vserver Svm -netgroup group1 -clientIP 172.18.162.242 -show-source true
Success
Hostname resolved to: myclient.netapp.com
Source used for lookup: NIS

cluster::*> getxxbyyy netgrpbyhost -node node01 -vserver Svm -netgroup group2 -clientIP 172.18.162.242 -show-source true
netgroup not found in netgroup.byhost lookup in all the configured sources
Hostname resolved to: myclient.netapp.com
Source used for lookup: Unknown

7. Interpret EMS events with the exact release catalog

Use event log show to inspect occurrences. The source’s definition-display example is corrected to the supported event catalog command:

event catalog show -message-name <message_name> -instance

The historical list mixes several release aliases and contains translated/corrupted event names. The table preserves their troubleshooting roles rather than inventing executable identifiers for broken aliases. Match the exact event identifier from the actual log to the release’s EMS catalog. Corrected spelling examples include exports.hostname.transient and secd.unexpectedFailure; LDAP errors concern LDAP, not the source’s incorrectly copied NIS descriptions.

Source event/family or described condition	What to inspect
Accesscache.NearLimits / Accesscache.ReachedLimit	Access-cache entry/export-rule capacity and current limits.
dns.server.timed.out	DNS response timeout, server health and network path.
exports.hostname.notFound; source host/data/cluster aliases	Missing forward hostname-to-IP data in the SVM name service.
exports.hostname.transient; source translated host-transient aliases	Forward resolution could not complete; inspect lookup/configuration failure details.
Source DNS-config event	DNS selected in the switch order but missing/incomplete DNS configuration.
exports.dom.notFound; source cluster/domain aliases	Missing reverse mapping used for a domain client-match.
Source domain-transient aliases	Failed reverse lookup of the client IP; inspect the actual EMS spelling and failure.
exports.netgroup.dnsNoPtrRec	Missing PTR mapping needed by the netgroup membership method.
exports.netgroup.notFound / exports.netgroup.partial	Missing netgroup or incomplete results from the configured source.
Source all-by-host-sources-failed event	All eligible by-host netgroup sources failed; local-file fallback was unavailable.
Source Nblade export-access evaluation event	Client access evaluation could not complete; read the exact event and rule context.
netgroup.files.missing	Local files selected but the required netgroup file is absent.
Source LDAP-by-host-missing / LDAP-config events	LDAP netgroup-by-host option or LDAP client configuration is missing/inconsistent.
netgroup.nis.byhost.decode	Invalid/undecodable response to a NIS by-host RPC lookup.
Source NIS-by-host-missing / NIS-config events	NIS map/configuration missing for a selected source; verify availability and data.
secd.authsys.lookup.failed	Incoming UNIX UID could not be found in the configured sources.
secd.dns.server.timed.out / secd.dns.srv.lookup.failed	DNS response timeout or failed service-record lookup.
secd.ldap.query.timed.out / secd.ldap.slowServer	LDAP response delay/timeout in the actual event context.
secd.ldap.noServers / source LDAP connection-failure event	LDAP servers unavailable or connections failing, including applicable TLS/authentication causes.
secd.netgroup.ldap.badFilter	Invalid LDAP search filter/client schema/netgroup query; affected membership cannot be assumed.
secd.nfsAuth.problem	NFS authorization failure; correlate its detailed identity and export/file-permission context.
secd.noNetgroupFile	Local-file netgroup source selected without a loaded usable file.
secd.nis.noServers / source NIS connection-failure event	NIS server availability or connection failure.
secd.ns.slowServer	Slow name-service response; do not assume it is always a NIS TCP-connect failure.
secd.unexpectedFailure	Unexpected SecD failure; inspect the accompanying detailed error journal.

8. Check the actual SVM LIF and routes

Inspect each relevant LIF’s address/mask, state, current node/port and route to the destination, correcting the source’s mistranslation of LIF as “lifecycle manager”:

cluster::> network interface show -vserver Svm
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
Svm
            Svm_lif1        up/up    172.18.162.6/16    node01
                                                                   e0c     true
            Svm_admin
                         up/up    172.18.162.14/24   node02
                                                                   e0d     true

cluster::> network route show -vserver Svm
Vserver             Destination     Gateway         Metric
------------------- --------------- --------------- ------
Svm
                    0.0.0.0/0       10.113.52.1     30
                    0.0.0.0/0       172.18.162.1    20

The two default routes shown have different metrics; the lower metric is preferred among otherwise applicable comparable routes. First consider the matching destination/prefix and actual reachability, rather than assuming the lowest number overrides all routing rules. Example addresses in these independent captures are not a validated end-to-end topology.

For a gateway 10.10.30.1, correct containing-prefix examples are 10.0.0.0/8,10.10.0.0/16 and 10.10.30.0/24. The source’s 10.10.10.0/24 example does not contain that gateway. Verify the actual subnet/mask and supported routed topology; do not infer a valid gateway merely from similar decimal octets.

Ping and traceroute

Select the actual SVM and source -lif when testing the data/name-service path; a node-management test can exercise a different route. The source lists the IPv4/IPv6 command families:

network ping | network ping6network traceroute | network traceroute6

Successful and failed source captures remain separate:

cluster::> network ping -lif test3 -vserver Svm -destination 172.18.162.1
172.18.162.1 is alive

cluster::> network ping -lif test3 -vserver Svm -destination 172.18.162.1 -v true -show-detail true
PING 172.18.162.1 (172.18.162.1) from 172.18.162.22: 56 data bytes
 to 172.18.162.22 64 bytes from 172.18.162.1: icmp_seq=0 ttl=128 time=1.815 ms

cluster::> network ping -lif test -vserver Svm -destination 8.8.8.8
no answer from 8.8.8.8
 
cluster::> network ping -lif test -vserver Svm -destination 8.8.8.8 -v true -show-detail true
ping: sendto: No route to host
Tracereoute
cluster::> network traceroute -lif test3 -vserver Svm -destination 8.8.8.8

Ping/traceroute test limited network behavior and do not prove that NFS, DNS, LDAP or SMB service traffic succeeds. Replies/probes can be filtered independently. The source describes 5-second waits and 3 queries per hop as defaults, which depend on the actual command/version. Asterisks mean no reply to those probes, not proof that forwarding stopped. Timeouts alone do not prove too many hops; inspect the actual response, filters and path.

Firewall, service policies and enabled protocols

Check client/network firewalls and the real service listeners; the source’s netstat -an command is normalized to an ASCII dash. Management firewall policy and a LIF service policy are distinct from an export rule. Historical firewall policies attach to LIFs, not LUNs. The source’s repeated NDMP labels and “lifecycles” are corrected below:

Historical policy	Service families in the source context	Source access scope / LIF role
Management	DNS, HTTP/HTTPS, NDMP/NDMPS, NTP, SNMP, SSH; verify the release’s actual list	0.0.0.0/0; cluster, SVM and node management LIFs
Intercluster	HTTPS and the applicable NDMP/NDMPS services	0.0.0.0/0; intercluster LIFs
Data	DNS and the applicable NDMP/NDMPS services	0.0.0.0/0; data LIFs

The source says service-policy transitions began around 9.6 and were complete at 9.11.1. Current primary guidance explicitly deprecates firewall policies and makes them empty beginning 9.10.1, with LIF service policies opening the applicable ports. Follow the actual release. Historical management firewall policies do not directly select NFS/SMB data protocols, while modern service policies determine supported LIF traffic; do not turn that distinction into a claim that NFS can never be blocked.

Check that the intended LIF and SVM actually permit the requested protocol, retaining the source’s NFS/CIFS and disallowed FCP/iSCSI examples:

cluster::> network interface show -vserver Svm -fields data-protocol
vserver lif                   data-protocol
------- --------------------- -------------
Svm     svm_lif1              nfs,cifs
 
cluster::> vserver show -vserver Svm -fields allowed-protocols
vserver allowed-protocols
------- -----------------------
Svm     nfs,cifs,ndmp

cluster::> vserver show -vserver Svm -fields disallowed-protocols
vserver disallowed-protocols
------- --------------------
Svm     fcp,iscsi

For the historical ipfilter.ReachedMaxStates condition, examine the event definition rather than assuming every connection problem is a full state table:

cluster::> event catalog show -message-name ipfilter.ReachedMaxStates -instance

                                     Message Name: ipfilter.ReachedMaxStates
                                        Severity: NOTICE
                                Corrective Action: (NONE)
                                      Description: This message occurs when the ipfilter firewall fails to create a new dynamic state entry for a 'keep-state' rule because the number of dynamic state entries has reached the maximum allowed value of 4013. The 'keep-state' rule is used by the firewall to keep track of whether a connection is established. States are maintained by firewall for TCP, UDP, and ICMP packets. This message occurs at most once every 60 seconds; it lists the most recent connections to reach the limit.

The 4013-entry maximum and 60-second report interval are values in this archived EMS excerpt, not limits promised for every ONTAP release.

Services and ports

Source service	Port
RPC portmapper	111
LDAP, if configured without a different/TLS endpoint	389
DNS	53
Kerberos	88

The source explains that NIS registers a dynamically chosen service port with RPC portmapper, which ONTAP queries on 111. This four-row list is not a complete NFS firewall matrix; account for NFS 2049 and the applicable version’s ancillary RPC/TLS services and transport directions.

Additional information

The message access denied by server while mounting commonly warrants inspecting export-policy matching, but identity/permissions and service reachability still need to be distinguished. Preserve the actual error, path, client identity and timing for the support case.