Pam_mount and laptop connected to wifi

gerald-salin · September 26, 2026, 4:53pm

Ubuntu Version

Ubuntu 24.04 LTS

Desktop Environment (if applicable)

GNOME

Problem Description

hi!
I would like my users to be able to access their network shares the same way, connected over ethernet or wifi.
Currently, my computers (ubuntu 24.04) are declared on active directory, network shares are mounted with pam_mount at user login and it is working well.

pam_mount does not mount network shares for laptop, when user logs in, connected with wifi…normal…
is there a way to call pam_mount after the user is logged in and vpn connected so that it behaves as if the user was connected with ethernet.

thank you for your help
Gerald

avb66 · September 26, 2026, 5:43pm

No. PAM by design runs when user is being logged in.

Some options you may consider

Use system connections that store WiFi credentials system-wide and connect to AP on system boot, like wired connections.
Use automounter that mounts on access

And think about the following - WiFi is unreliable and may fail more easily than Ethernet. Any solution needs to handle it. Automounter comes close - it will attempt to remount after connection is reestablished if configured properly.

et-ducky · September 26, 2026, 6:46pm

Put -fstype=cifs,sec=krb5,cruid=${UID},uid=${UID} in the autofs map on the laptops so each share mounts with the logged-in user’s Kerberos ticket. A user who signed in before the VPN connected has no ticket yet, so set krb5_store_password_if_offline = True in the domain section of /etc/sssd/sssd.conf and SSSD requests one once a domain controller is reachable. Run klist after the VPN connects and check that it lists a krbtgt ticket for your realm before opening a share.

Drafted with AI.

gerald-salin · September 26, 2026, 7:45pm

thank you for the tips, I’ll test it next week!
have a nice WE
Gérald

fireon · September 28, 2026, 7:21am

I workaround could also be to access localhost via SSH.

ssh localhost

That would be a single login, and all drives (if accessible) will be connected.

gerald-salin · September 29, 2026, 3:21pm

Hi,
I installed autofs and configured it to work with local credentials

> cat /etc/auto.master.d/cifs.autofs 
/share	/etc/autofs.cifs

> ll -d /share
drwxr-xr-x 3 root root 0 sept. 29 11:31 /share/

> cat /etc/autofs.cifs
* -fstype=cifs,rw,noperm,credentials=/home/MYACCOUNT/.smbcredentials :/MYSERVER.FR/user/home/&

autofs restarted, works like a charm (either laptop connected over ethernet, or wifi+VPN), I can access the content of my home directory in /share/MYACCOUNT

I then tried using kerberos…

> cat /etc/autofs.cifs
* -fstype=cifs,rw,noperm,sec=krb5,cruid=${UID},uid=${UID} :/MYSERVER.FR/user/home/&

autofs restarted, I can’t access the content of my home directory, even if laptop connected over ethernet. I rebooted, just to be sure…but the the problem remains

>tail -f /var/log/syslog
2026-09-29T12:17:01.001098+02:00 COMPUTER-NAME kernel: CIFS: Attempting to mount //MYSERVER.FR/user/home/MYACCOUNT
2026-09-29T12:17:01.008644+02:00 COMPUTER-NAME cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=MYSERVER.FR;ip4=xxx.xxx.xxx.xxx;sec=krb5;uid=0x0;creduid=0x0;user=root;pid=0x110a;upcall_target=app
2026-09-29T12:17:01.009657+02:00 COMPUTER-NAME cifs.upcall: ver=2
2026-09-29T12:17:01.009940+02:00 COMPUTER-NAME cifs.upcall: host=MYSERVER.FR
2026-09-29T12:17:01.010238+02:00 COMPUTER-NAME cifs.upcall: ip=xxx.xxx.xxx.xxx
2026-09-29T12:17:01.010498+02:00 COMPUTER-NAME cifs.upcall: sec=1
2026-09-29T12:17:01.010699+02:00 COMPUTER-NAME cifs.upcall: uid=0
2026-09-29T12:17:01.010907+02:00 COMPUTER-NAME cifs.upcall: creduid=0
2026-09-29T12:17:01.011152+02:00 COMPUTER-NAME cifs.upcall: user=root
2026-09-29T12:17:01.011396+02:00 COMPUTER-NAME cifs.upcall: pid=4362
2026-09-29T12:17:01.011504+02:00 COMPUTER-NAME cifs.upcall: upcall_target=app
2026-09-29T12:17:01.011585+02:00 COMPUTER-NAME cifs.upcall: upcall_target=app, switching namespaces to application thread
2026-09-29T12:17:01.011928+02:00 COMPUTER-NAME cifs.upcall: get_cachename_from_process_env: pid == 0
2026-09-29T12:17:01.012384+02:00 COMPUTER-NAME cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_0
2026-09-29T12:17:01.012710+02:00 COMPUTER-NAME cifs.upcall: check_service_ticket_exists: unable to get client principal from cache: No credentials cache found (filename: /tmp/krb5cc_0)
2026-09-29T12:17:01.012894+02:00 COMPUTER-NAME cifs.upcall: get_tgt_time: unable to get principal
2026-09-29T12:17:01.013142+02:00 COMPUTER-NAME cifs.upcall: main: valid TGT is not present in credential cache
2026-09-29T12:17:01.013298+02:00 COMPUTER-NAME cifs.upcall: krb5_get_init_creds_keytab: -1765328203
2026-09-29T12:17:01.013454+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: getting service ticket for MYSERVER.FR
2026-09-29T12:17:01.013615+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: using GSS-API
2026-09-29T12:17:01.018416+02:00 COMPUTER-NAME cifs.upcall: GSS-API error init_sec_context: No credentials were supplied, or the credentials were unavailable or inaccessible
2026-09-29T12:17:01.018866+02:00 COMPUTER-NAME cifs.upcall: GSS-API error init_sec_context: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0)
2026-09-29T12:17:01.019087+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: failed to obtain service ticket via GSS (458752)
2026-09-29T12:17:01.019275+02:00 COMPUTER-NAME cifs.upcall: Unable to obtain service ticket
2026-09-29T12:17:01.019449+02:00 COMPUTER-NAME cifs.upcall: Exit status 458752
2026-09-29T12:17:01.020087+02:00 COMPUTER-NAME kernel: CIFS: VFS: \\MYSERVER.FR failed to create a new SMB session with Kerberos: -126
2026-09-29T12:17:01.020113+02:00 COMPUTER-NAME kernel: CIFS: VFS: cifs_mount failed w/return code = -126

my sssd.conf file seems OK :

> cat /etc/sssd/sssd.conf 
[sssd]
domains = XXX.local
config_file_version = 2
services = nss,pam


[domain/XXX.local]
ad_domain = XXX.local
krb5_realm = XXX.LOCAL
realmd_tags = manages-system joined-with-samba
# cache des autorisations
cache_credentials = true
# fournisseur des identités et des autorisations
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = true
# paramètrage de l'identité / mapping
default_shell = /bin/bash
ldap_id_mapping = false
use_fully_qualified_names = false
access_provider = ad
enumerate = true
ldap_user_principal = userPrincipalName
ldap_user_name = samAccountNAme
ad_gpo_access_control = disabled
fallback_homedir = /home/%u

debug_level = 5
# Intégration dans le DNS
dns_discovery_domain = XXX.local
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600

any idea what could be wrong?

Gérald

et-ducky · September 29, 2026, 5:10pm

The mount asked for root’s Kerberos ticket instead of yours, so ${UID} most likely expanded to 0 on that attempt. Was /share/MYACCOUNT first opened from your own desktop session, or from a root shell or sudo?

Drafted with AI.

gerald-salin · September 30, 2026, 10:15am

hum sorry, I guess it was the log for my test without cruid=${UID}uid=${UID}

below is the log for my morning test :

boot the laptop (without ethernet)
connect to my AD session MYACCOUNT (regular account without sudo rights)
connect to WIFI
connect to VPN
access /share/MYACCOUNT from a terminal : ls /share/MYACCOUNT > No such file or directory

2026-09-30T08:12:10.503774+02:00 COMPUTER-NAME kernel: CIFS: enabling forceuid mount option implicitly because uid= option is specified
2026-09-30T08:12:10.503800+02:00 COMPUTER-NAME kernel: CIFS: Attempting to mount //MYSERVER.FR/user/home/MYACCOUNT
2026-09-30T08:12:10.521022+02:00 COMPUTER-NAME cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=MYSERVER.FR.fr;ip4=xxx.xxx.xxx.xxx;sec=krb5;uid=0x24a1;creduid=0x24a1;user=root;pid=0x1d22;upcall_target=app
2026-09-30T08:12:10.521537+02:00 COMPUTER-NAME cifs.upcall: ver=2
2026-09-30T08:12:10.521709+02:00 COMPUTER-NAME cifs.upcall: host=MYSERVER.FR
2026-09-30T08:12:10.521853+02:00 COMPUTER-NAME cifs.upcall: ip=xxx.xxx.xxx.xxx
2026-09-30T08:12:10.521979+02:00 COMPUTER-NAME cifs.upcall: sec=1
2026-09-30T08:12:10.522101+02:00 COMPUTER-NAME cifs.upcall: uid=9377
2026-09-30T08:12:10.522224+02:00 COMPUTER-NAME cifs.upcall: creduid=9377
2026-09-30T08:12:10.522352+02:00 COMPUTER-NAME cifs.upcall: user=root
2026-09-30T08:12:10.522482+02:00 COMPUTER-NAME cifs.upcall: pid=7458
2026-09-30T08:12:10.522610+02:00 COMPUTER-NAME cifs.upcall: upcall_target=app
2026-09-30T08:12:10.524549+02:00 COMPUTER-NAME cifs.upcall: upcall_target=app, switching namespaces to application thread
2026-09-30T08:12:10.525155+02:00 COMPUTER-NAME cifs.upcall: get_cachename_from_process_env: pathname=/proc/7458/environ 
2026-09-30T08:12:10.525571+02:00 COMPUTER-NAME cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_9377
2026-09-30T08:12:10.525817+02:00 COMPUTER-NAME cifs.upcall: check_service_ticket_exists: unable to get client principal from cache: No credentials cache found (filename: /tmp/krb5cc_9377)
2026-09-30T08:12:10.525948+02:00 COMPUTER-NAME cifs.upcall: get_tgt_time: unable to get principal
2026-09-30T08:12:10.526074+02:00 COMPUTER-NAME cifs.upcall: main: valid TGT is not present in credential cache
2026-09-30T08:12:10.582807+02:00 COMPUTER-NAME cifs.upcall: krb5_get_init_creds_keytab: -1765328378
2026-09-30T08:12:10.582988+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: getting service ticket for MYSERVER.FR
2026-09-30T08:12:10.583115+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: using GSS-API
2026-09-30T08:12:10.589299+02:00 COMPUTER-NAME cifs.upcall: GSS-API error init_sec_context: No credentials were supplied, or the credentials were unavailable or inaccessible
2026-09-30T08:12:10.589483+02:00 COMPUTER-NAME cifs.upcall: GSS-API error init_sec_context: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_9377)
2026-09-30T08:12:10.589635+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: failed to obtain service ticket via GSS (458752)
2026-09-30T08:12:10.589790+02:00 COMPUTER-NAME cifs.upcall: Unable to obtain service ticket
2026-09-30T08:12:10.589920+02:00 COMPUTER-NAME cifs.upcall: Exit status 458752
2026-09-30T08:12:10.590767+02:00 COMPUTER-NAME kernel: CIFS: VFS: \\MYSERVER.FR failed to create a new SMB session with Kerberos: -126
2026-09-30T08:12:10.590789+02:00 COMPUTER-NAME kernel: CIFS: VFS: cifs_mount failed w/return code = -126

I’ll go on investigation…
thank you for your help
Gérald

et-ducky · September 30, 2026, 2:52pm

The mount now runs with your uid, so the failure is the missing Kerberos ticket at /tmp/krb5cc_9377. It’s most likely that you signed in before a domain controller was reachable, or SSSD wrote your ticket cache under a different name. What does klist show right after the VPN connects?

Drafted with AI.

gerald-salin · October 2, 2026, 6:34am

Hi
I tested the easier case, laptop connected over ethernet…but no more luck.

below is the log for my morning test :

boot the laptop (with ethernet)
connect to my AD session MYACCOUNT (regular account without sudo rights)
access /share/MYACCOUNT from a terminal : ls /share/MYACCOUNT > No such file or directory

syslog says :

2026-10-02T08:18:47.328991+02:00 COMPUTER-NAME kernel: CIFS: enabling forceuid mount option implicitly because uid= option is specified
2026-10-02T08:18:47.329004+02:00 COMPUTER-NAME kernel: CIFS: Attempting to mount //MYSERVER.FR/user/home/MYACCOUNT
2026-10-02T08:18:47.331371+02:00 COMPUTER-NAME cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=MYSERVER.FR;ip4=XXX.XXX.XXX.XXX;sec=krb5;uid=0x24a1;creduid=0x24a1;user=root;pid=0x1169;upcall_target=app
2026-10-02T08:18:47.331608+02:00 COMPUTER-NAME cifs.upcall: ver=2
2026-10-02T08:18:47.331676+02:00 COMPUTER-NAME cifs.upcall: host=MYSERVER.FR
2026-10-02T08:18:47.331731+02:00 COMPUTER-NAME cifs.upcall: ip=XXX.XXX.XXX.XXX
2026-10-02T08:18:47.331783+02:00 COMPUTER-NAME cifs.upcall: sec=1
2026-10-02T08:18:47.331836+02:00 COMPUTER-NAME cifs.upcall: uid=9377
2026-10-02T08:18:47.331890+02:00 COMPUTER-NAME cifs.upcall: creduid=9377
2026-10-02T08:18:47.331948+02:00 COMPUTER-NAME cifs.upcall: user=root
2026-10-02T08:18:47.332015+02:00 COMPUTER-NAME cifs.upcall: pid=4457
2026-10-02T08:18:47.332076+02:00 COMPUTER-NAME cifs.upcall: upcall_target=app
2026-10-02T08:18:47.332913+02:00 COMPUTER-NAME cifs.upcall: upcall_target=app, switching namespaces to application thread
2026-10-02T08:18:47.333191+02:00 COMPUTER-NAME cifs.upcall: get_cachename_from_process_env: pathname=/proc/4457/environ
2026-10-02T08:18:47.333417+02:00 COMPUTER-NAME cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_9377
2026-10-02T08:18:47.333546+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: getting service ticket for MYSERVER.FR
2026-10-02T08:18:47.333602+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: using native krb5
2026-10-02T08:18:47.392941+02:00 COMPUTER-NAME cifs.upcall: cifs_krb5_get_req: unable to get credentials for MYSERVER.FR
2026-10-02T08:18:47.393144+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328377)
2026-10-02T08:18:47.393261+02:00 COMPUTER-NAME cifs.upcall: Unable to obtain service ticket
2026-10-02T08:18:47.393383+02:00 COMPUTER-NAME cifs.upcall: Exit status -1765328377
2026-10-02T08:18:47.394022+02:00 COMPUTER-NAME kernel: CIFS: VFS: \\MYSERVER.FR failed to create a new SMB session with Kerberos: -126
2026-10-02T08:18:47.394043+02:00 COMPUTER-NAME kernel: CIFS: VFS: cifs_mount failed w/return code = -126

klist seems fine :

root@COMPUTER-NAME:/home/MYACCOUNT# klist
Ticket cache: FILE:/tmp/krb5cc_9377
Default principal: MYACCOUNT@XXX.LOCAL

Valid starting       Expires              Service principal
02/10/2026 08:16:16  02/10/2026 18:16:16  krbtgt/XXX.LOCAL@XXX.LOCAL
	renew until 09/10/2026 08:16:16

any idea?

avb66 · October 2, 2026, 7:47am

Can you mount it manually using exactly the same parameters as in autofs configuration?

steelf · October 2, 2026, 8:03am

That error -1765328377 means the domain controller does not know who MYSERVER.FR is.
Your Kerberos ticket is for XXX.LOCAL, not .FR.

When you test manual mount like @avb66 said, try using the AD name instead of .FR:
//MYSERVER.XXX.LOCAL/user/home/MYACCOUNT

Or add servern=MYSERVER.XXX.LOCAL to your mount options.

gerald-salin · October 2, 2026, 5:22pm

Tried, but I don’t know how to get the AD name of my cifs server…
I’ll go on next week…
thank you for your hepl
Gérald

gerald-salin · October 2, 2026, 5:31pm

I have exactly the same error trying the mount through fstab with
//MYSERVER.FR/user/home/MYACCOUNT /share/MYACCOUNT cifs sec=krb5,vers=3,multiuser,cruid=MYACCOUNT,uid=9377,domain=XXX.LOCAL,noauto,user

2026-10-02T19:23:21.854669+02:00 COMPUTER-NAME kernel: CIFS: enabling forcegid mount option implicitly because gid= option is specified
2026-10-02T19:23:21.854672+02:00 COMPUTER-NAME kernel: CIFS: Attempting to mount //MYSERVER.FR/user/home/MYACCOUNT
2026-10-02T19:23:21.858002+02:00 COMPUTER-NAME cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=MYSERVER.FR;ip4=XXX.XXX.XXX.XXX;sec=krb5;uid=0x24a1;creduid=0x24a1;user=MYACCOUNT;pid=0x139e;upcall_target=app
2026-10-02T19:23:21.858263+02:00 COMPUTER-NAME cifs.upcall: ver=2
2026-10-02T19:23:21.858319+02:00 COMPUTER-NAME cifs.upcall: host=MYSERVER.FR
2026-10-02T19:23:21.858367+02:00 COMPUTER-NAME cifs.upcall: ip=XXX.XXX.XXX.XXX
2026-10-02T19:23:21.858411+02:00 COMPUTER-NAME cifs.upcall: sec=1
2026-10-02T19:23:21.858451+02:00 COMPUTER-NAME cifs.upcall: uid=9377
2026-10-02T19:23:21.858495+02:00 COMPUTER-NAME cifs.upcall: creduid=9377
2026-10-02T19:23:21.858541+02:00 COMPUTER-NAME cifs.upcall: user=MYACCOUNT
2026-10-02T19:23:21.858591+02:00 COMPUTER-NAME cifs.upcall: pid=5022
2026-10-02T19:23:21.858654+02:00 COMPUTER-NAME cifs.upcall: upcall_target=app
2026-10-02T19:23:21.859435+02:00 COMPUTER-NAME cifs.upcall: upcall_target=app, switching namespaces to application thread
2026-10-02T19:23:21.860403+02:00 COMPUTER-NAME cifs.upcall: get_cachename_from_process_env: pathname=/proc/5022/environ
2026-10-02T19:23:21.860484+02:00 COMPUTER-NAME cifs.upcall: get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_9377
2026-10-02T19:23:21.860677+02:00 COMPUTER-NAME cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_9377
2026-10-02T19:23:21.860760+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: getting service ticket for MYSERVER.FR
2026-10-02T19:23:21.860809+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: using native krb5
2026-10-02T19:23:21.891435+02:00 COMPUTER-NAME cifs.upcall: cifs_krb5_get_req: unable to get credentials for MYSERVER.FR
2026-10-02T19:23:21.891519+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328377)
2026-10-02T19:23:21.891571+02:00 COMPUTER-NAME cifs.upcall: Unable to obtain service ticket
2026-10-02T19:23:21.891628+02:00 COMPUTER-NAME cifs.upcall: Exit status -1765328377
2026-10-02T19:23:21.892660+02:00 COMPUTER-NAME kernel: CIFS: VFS: \\MYSERVER.FR failed to create a new SMB session with Kerberos: -126
2026-10-02T19:23:21.892669+02:00 COMPUTER-NAME kernel: CIFS: VFS: cifs_mount failed w/return code = -126

so I have to find how to deal with this cifs server…

avb66 · October 2, 2026, 5:34pm

Did it ever work? Were you able to mount anything from your file servers using Kerberos authentication?

steelf · October 2, 2026, 5:35pm

You are still mounting //MYSERVER.FR. The domain controller only knows cifs/MYSERVER.XXX.LOCAL, which is why it returns -1765328377 (principal unknown).

Try mounting with the AD domain name:
//MYSERVER.XXX.LOCAL/user/home/MYACCOUNT

If it does not resolve, put the IP and MYSERVER.XXX.LOCAL into /etc/hosts first.

et-ducky · October 2, 2026, 7:31pm

It isn’t the ticket, then.

To find the name AD knows for the server, run host MYSERVER.FR to get its IP, then run host followed by that IP. When your DNS points at the domain controllers, the reverse lookup usually returns a name ending in .XXX.LOCAL.

Test that name before changing the mount (replace MYSERVER.XXX.LOCAL with what the lookup returned):

kvno cifs/MYSERVER.XXX.LOCAL

If it prints kvno = followed by a number, that name will work in your autofs map.

Drafted with AI.

gerald-salin · October 4, 2026, 8:33am

Hi,
I used to mount these cifs shares with a local credentials file, configured in fstab, works well…now, I would like to switch to kerberos…but is seems harder to configure…so no, it never worked with kerberos
My users can connect on their linux boxes with their AD logins, the TGT is well created for them
seems the problem comes from the service ticket sor the url hosting the windows share

gerald-salin · October 4, 2026, 8:44am

tried that without success too, same error

2026-10-04T19:23:21.860760+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: getting service ticket for MYSERVER.XXX.local
2026-10-04T19:23:21.860809+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: using native krb5
2026-10-04T19:23:21.891435+02:00 COMPUTER-NAME cifs.upcall: cifs_krb5_get_req: unable to get credentials for MYSERVER.XXX.local
2026-10-04T19:23:21.891519+02:00 COMPUTER-NAME cifs.upcall: handle_krb5_mech: failed to obtain service ticket (-1765328377)
2026-10-04T19:23:21.891571+02:00 COMPUTER-NAME cifs.upcall: Unable to obtain service ticket

with following configuration
in /etc/hosts

XXX.XXX.XXX.XXX MYSERVER.XXX.local
XXX.XXX.XXX.XXX MYSERVER.XXX.LOCAL
XXX.XXX.XXX.XXX MYSERVER.fr

in /etc/fstab :

//MYSERVER.XXX.LOCAL/user/home/MYACCOUNT /share/MYACCOUNT cifs sec=krb5,vers=3,multiuser,cruid=MYACCOUNT,uid=9377,domain=XXX.LOCAL,noauto,user

pfff, thank you for your help

gerald-salin · October 4, 2026, 8:51am

hum :
host MYSERVER.FR returns XXX.XXX.XXX.XXX
host XXX.XXX.XXX.XXX returns : Host XXX.XXX.XXX.XXX.in-addr.arpa not found : 3 (NXDOMAIN)

If i set XXX.XXX.XXX.XXX MYSERVER.XXX.LOCAL in /etc/hosts
host XXX.XXX.XXX.XXX returns : XXX.XXX.XXX.XXX.in-addr.arpa domain name pointer MYSERVER.XXX.LOCAL

but the mount does not succeed, with the exact same error :
unable to get credentials for MYSERVER.XXX.local