Permission denied mounting a DFS share with multiuser options

Permission denied mounting a DFS share with multiuser options

[abrosich]

Hello,

I'm trying to configure a linux client (Unubtu 18.04.3) to mount a DFS
share from a windows server 2019. Both machines are joined in the same
Active Directory domain. I joined the linux client using the "realm"
command and it works fine: for example I can login with ssh using AD
credentials.

The package cifs-utils is version 6.8.

I start by saying that I have a little konwledge of the windows world
and in particular of SMB, hence my question could by silly but I
searched for days without find any solution.

I found the following entries in the krb5.conf file (I suppose added by
"realm" coomand): 
3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (des-cbc-crc) 
   3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (des-cbc-md5) 
   3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (arcfour-hmac) 
   3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (aes128-cts-hmac-
sha1-96) 
   3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (aes256-cts-hmac-
sha1-96) 
   3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (des-cbc-crc) 
   3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (des-cbc-md5) 
   3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (arcfour-hmac) 
   3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (aes128-cts-hmac-
sha1-96) 
   3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (aes256-cts-hmac-
sha1-96) 

I created on the Domain Controller a user principal "linuxclientuser-
cifs" and associated to it an SPN "cifs/linuxclient.fqdn@AD.DOMAIN". I
exported the keytab file and added it in krb5.keytab where I have now
the followind entries:

  3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (des-cbc-crc) 
   3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (des-cbc-md5) 
   3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (arcfour-hmac) 
   3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (aes256-cts-
hmac-sha1-96) 
   3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (aes128-cts-
hmac-sha1-96) 


I use the following command to mount the share:
sudo mount --verbose --types cifs //winsrv/CifsShare /mnt/cifs --
options
sec=krb5,multiuser,vers=3,user=cifs/linuxclient.fqdn,domain=AD.DOMAIN

and the response is: "mount error(13): Permission denied"

Looking at logs I find:
Nov 27 13:07:18 linuxclient cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=winsrv;ip4=XXX.XXX.XXX.XXX;sec=kr
b5;uid=0x0;creduid=0x0;user=cifs/linuxclient.fqdn;pid=0x6ac
Nov 27 13:07:18 linuxclient cifs.upcall: ver=2
Nov 27 13:07:18 linuxclient cifs.upcall: host=winsrv
Nov 27 13:07:18 linuxclient cifs.upcall: ip=XXX.XXX.XXX.XXX
Nov 27 13:07:18 linuxclient cifs.upcall: sec=1
Nov 27 13:07:18 linuxclient cifs.upcall: uid=0
Nov 27 13:07:18 linuxclient cifs.upcall: creduid=0
Nov 27 13:07:18 linuxclient cifs.upcall: user=cifs/linuxclient.fqdn
Nov 27 13:07:18 linuxclient cifs.upcall: pid=1708
Nov 27 13:07:18 linuxclient cifs.upcall:
get_cachename_from_process_env: pid == 0
Nov 27 13:07:18 linuxclient cifs.upcall: get_existing_cc: default
ccache is FILE:/tmp/krb5cc_0
Nov 27 13:07:18 linuxclient cifs.upcall: get_tgt_time: unable to get
principal
Nov 27 13:07:18 linuxclient cifs.upcall: handle_krb5_mech: getting
service ticket for winsrv
Nov 27 13:07:18 linuxclient cifs.upcall: handle_krb5_mech: obtained
service ticket
Nov 27 13:07:18 linuxclient cifs.upcall: Exit status 0


where it says that it get the service ticket (I can see it sniffing
packets with wireshark) but it is "unable to get principal". Which
principal?

On the server side I have the following error:

A process has requested access to an object, but has not been granted
those access rights. (0xC0000022)
SPN: session setup failed before the SPN could be queried
SPN Validation Policy: SPN optional / no validation


What I'm doing wrong?

Any suggest is welcome.

Best regards

Alberto

Re: Permission denied mounting a DFS share with multiuser options

[Steve French]

Have you experimented with a newer kernel (e.g. Ubuntu 19 or the
download from the Ubuntu mainline kernel download site) to see if some
of Paulo's DFS fixes (e.g. a large set went in last year) help.

On Wed, Nov 27, 2019 at 6:20 AM <abrosich@inogs.it> wrote:
>
>
> Hello,
>
> I'm trying to configure a linux client (Unubtu 18.04.3) to mount a DFS
> share from a windows server 2019. Both machines are joined in the same
> Active Directory domain. I joined the linux client using the "realm"
> command and it works fine: for example I can login with ssh using AD
> credentials.
>
> The package cifs-utils is version 6.8.
>
> I start by saying that I have a little konwledge of the windows world
> and in particular of SMB, hence my question could by silly but I
> searched for days without find any solution.
>
> I found the following entries in the krb5.conf file (I suppose added by
> "realm" coomand):
> 3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (des-cbc-crc)
>    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (des-cbc-md5)
>    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (arcfour-hmac)
>    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (aes128-cts-hmac-
> sha1-96)
>    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (aes256-cts-hmac-
> sha1-96)
>    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (des-cbc-crc)
>    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (des-cbc-md5)
>    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (arcfour-hmac)
>    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (aes128-cts-hmac-
> sha1-96)
>    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (aes256-cts-hmac-
> sha1-96)
>
> I created on the Domain Controller a user principal "linuxclientuser-
> cifs" and associated to it an SPN "cifs/linuxclient.fqdn@AD.DOMAIN". I
> exported the keytab file and added it in krb5.keytab where I have now
> the followind entries:
>
>   3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (des-cbc-crc)
>    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (des-cbc-md5)
>    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (arcfour-hmac)
>    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (aes256-cts-
> hmac-sha1-96)
>    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (aes128-cts-
> hmac-sha1-96)
>
>
> I use the following command to mount the share:
> sudo mount --verbose --types cifs //winsrv/CifsShare /mnt/cifs --
> options
> sec=krb5,multiuser,vers=3,user=cifs/linuxclient.fqdn,domain=AD.DOMAIN
>
> and the response is: "mount error(13): Permission denied"
>
> Looking at logs I find:
> Nov 27 13:07:18 linuxclient cifs.upcall: key description:
> cifs.spnego;0;0;39010000;ver=0x2;host=winsrv;ip4=XXX.XXX.XXX.XXX;sec=kr
> b5;uid=0x0;creduid=0x0;user=cifs/linuxclient.fqdn;pid=0x6ac
> Nov 27 13:07:18 linuxclient cifs.upcall: ver=2
> Nov 27 13:07:18 linuxclient cifs.upcall: host=winsrv
> Nov 27 13:07:18 linuxclient cifs.upcall: ip=XXX.XXX.XXX.XXX
> Nov 27 13:07:18 linuxclient cifs.upcall: sec=1
> Nov 27 13:07:18 linuxclient cifs.upcall: uid=0
> Nov 27 13:07:18 linuxclient cifs.upcall: creduid=0
> Nov 27 13:07:18 linuxclient cifs.upcall: user=cifs/linuxclient.fqdn
> Nov 27 13:07:18 linuxclient cifs.upcall: pid=1708
> Nov 27 13:07:18 linuxclient cifs.upcall:
> get_cachename_from_process_env: pid == 0
> Nov 27 13:07:18 linuxclient cifs.upcall: get_existing_cc: default
> ccache is FILE:/tmp/krb5cc_0
> Nov 27 13:07:18 linuxclient cifs.upcall: get_tgt_time: unable to get
> principal
> Nov 27 13:07:18 linuxclient cifs.upcall: handle_krb5_mech: getting
> service ticket for winsrv
> Nov 27 13:07:18 linuxclient cifs.upcall: handle_krb5_mech: obtained
> service ticket
> Nov 27 13:07:18 linuxclient cifs.upcall: Exit status 0
>
>
> where it says that it get the service ticket (I can see it sniffing
> packets with wireshark) but it is "unable to get principal". Which
> principal?
>
> On the server side I have the following error:
>
> A process has requested access to an object, but has not been granted
> those access rights. (0xC0000022)
> SPN: session setup failed before the SPN could be queried
> SPN Validation Policy: SPN optional / no validation
>
>
> What I'm doing wrong?
>
> Any suggest is welcome.
>
> Best regards
>
> Alberto
>
>


-- 
Thanks,

Steve

Re: Permission denied mounting a DFS share with multiuser options

[abrosich]

Hello Steve,
after a while I'am trying again to find a solution.

I've changed the environment.
The linux client now is a Debian machine with testing flavour to have the latest
versions of the involved softwares. These are the versions of some of them:

Kernel: #1 SMP Debian 5.4.19-1 (2020-02-13)
cifs.upcall: version: 6.9
keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
sssd: 2.2.3
cifs module: 2.23

The linux machine is joined in the AD domain. I can log on using ssh as domain
user and I can use smbclient with "-k" option after obtaining a ticket using
"kinit".

When I try to do a mount

mount --type cifs --verbose //server.domain/ShareName /mountpoint --options
sec=krb5i,username=domainuser,domain=ad.domain

I receive the following error:
mount error(2): No such file or directory

and dmesg gives:

CIFS VFS: \\server.domain Send error in SessSetup = -126
fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 54) rc = -126
...
CIFS VFS: cifs_mount failed w/return code = -2

Raising log level as in 
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting gives (to me) no
useful information about the cause.

What does it mean "Send error in SessSetup"? And error -126?

In the event viewer of the windows server I cannot find any event related to it.

I sniffed the ethernet conversation using wireshark. The conversation is quite
short (9 packets). The client closes it with a FIN,ACK after receiving a good
SMB Negotiate Protocol Response that seems good to me. The version of the
protocol is correctly set (3.1.1 when it is not specified).

Any suggest?

Best regards

Alberto


On Tue, 2019-12-03 at 16:16 -0600, Steve French wrote:
> Have you experimented with a newer kernel (e.g. Ubuntu 19 or the
> download from the Ubuntu mainline kernel download site) to see if some
> of Paulo's DFS fixes (e.g. a large set went in last year) help.
> 
> On Wed, Nov 27, 2019 at 6:20 AM <abrosich@inogs.it> wrote:
> > 
> > Hello,
> > 
> > I'm trying to configure a linux client (Unubtu 18.04.3) to mount a DFS
> > share from a windows server 2019. Both machines are joined in the same
> > Active Directory domain. I joined the linux client using the "realm"
> > command and it works fine: for example I can login with ssh using AD
> > credentials.
> > 
> > The package cifs-utils is version 6.8.
> > 
> > I start by saying that I have a little konwledge of the windows world
> > and in particular of SMB, hence my question could by silly but I
> > searched for days without find any solution.
> > 
> > I found the following entries in the krb5.conf file (I suppose added by
> > "realm" coomand):
> > 3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (des-cbc-crc)
> >    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (des-cbc-md5)
> >    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (arcfour-hmac)
> >    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (aes128-cts-hmac-
> > sha1-96)
> >    3 11/11/19 08:54:09 host/LINUXCLIENT@AD.DOMAIN (aes256-cts-hmac-
> > sha1-96)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (des-cbc-crc)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (des-cbc-md5)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (arcfour-hmac)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (aes128-cts-hmac-
> > sha1-96)
> >    3 11/11/19 08:54:09 host/linuxclient@AD.DOMAIN (aes256-cts-hmac-
> > sha1-96)
> > 
> > I created on the Domain Controller a user principal "linuxclientuser-
> > cifs" and associated to it an SPN "cifs/linuxclient.fqdn@AD.DOMAIN". I
> > exported the keytab file and added it in krb5.keytab where I have now
> > the followind entries:
> > 
> >   3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (des-cbc-crc)
> >    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (des-cbc-md5)
> >    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (arcfour-hmac)
> >    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (aes256-cts-
> > hmac-sha1-96)
> >    3 11/12/19 12:50:59 cifs/linuxclient.fqdn@AD.DOMAIN (aes128-cts-
> > hmac-sha1-96)
> > 
> > 
> > I use the following command to mount the share:
> > sudo mount --verbose --types cifs //winsrv/CifsShare /mnt/cifs --
> > options
> > sec=krb5,multiuser,vers=3,user=cifs/linuxclient.fqdn,domain=AD.DOMAIN
> > 
> > and the response is: "mount error(13): Permission denied"
> > 
> > Looking at logs I find:
> > Nov 27 13:07:18 linuxclient cifs.upcall: key description:
> > cifs.spnego;0;0;39010000;ver=0x2;host=winsrv;ip4=XXX.XXX.XXX.XXX;sec=kr
> > b5;uid=0x0;creduid=0x0;user=cifs/linuxclient.fqdn;pid=0x6ac
> > Nov 27 13:07:18 linuxclient cifs.upcall: ver=2
> > Nov 27 13:07:18 linuxclient cifs.upcall: host=winsrv
> > Nov 27 13:07:18 linuxclient cifs.upcall: ip=XXX.XXX.XXX.XXX
> > Nov 27 13:07:18 linuxclient cifs.upcall: sec=1
> > Nov 27 13:07:18 linuxclient cifs.upcall: uid=0
> > Nov 27 13:07:18 linuxclient cifs.upcall: creduid=0
> > Nov 27 13:07:18 linuxclient cifs.upcall: user=cifs/linuxclient.fqdn
> > Nov 27 13:07:18 linuxclient cifs.upcall: pid=1708
> > Nov 27 13:07:18 linuxclient cifs.upcall:
> > get_cachename_from_process_env: pid == 0
> > Nov 27 13:07:18 linuxclient cifs.upcall: get_existing_cc: default
> > ccache is FILE:/tmp/krb5cc_0
> > Nov 27 13:07:18 linuxclient cifs.upcall: get_tgt_time: unable to get
> > principal
> > Nov 27 13:07:18 linuxclient cifs.upcall: handle_krb5_mech: getting
> > service ticket for winsrv
> > Nov 27 13:07:18 linuxclient cifs.upcall: handle_krb5_mech: obtained
> > service ticket
> > Nov 27 13:07:18 linuxclient cifs.upcall: Exit status 0
> > 
> > 
> > where it says that it get the service ticket (I can see it sniffing
> > packets with wireshark) but it is "unable to get principal". Which
> > principal?
> > 
> > On the server side I have the following error:
> > 
> > A process has requested access to an object, but has not been granted
> > those access rights. (0xC0000022)
> > SPN: session setup failed before the SPN could be queried
> > SPN Validation Policy: SPN optional / no validation
> > 
> > 
> > What I'm doing wrong?
> > 
> > Any suggest is welcome.
> > 
> > Best regards
> > 
> > Alberto
> > 
> > 
> 
> 

Re: Permission denied mounting a DFS share with multiuser options

[Paulo Alcantara]

abrosich@inogs.it writes:

> I've changed the environment.
> The linux client now is a Debian machine with testing flavour to have the latest
> versions of the involved softwares. These are the versions of some of them:
>
> Kernel: #1 SMP Debian 5.4.19-1 (2020-02-13)
> cifs.upcall: version: 6.9
> keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
> sssd: 2.2.3
> cifs module: 2.23

I'd guess the following commit would fix your issue:

    5739375ee423 ("cifs: Fix mount options set in automount")

but could you please try it with 5.6-rc4?

Provide full dmesg logs as well.

Re: Permission denied mounting a DFS share with multiuser options

[abrosich]

Hello,

I installed kernel version 5.6-rc4 but nothing changed.

This is the command line:

sudo kinit domainuser
sudo mount --type cifs --verbose //server.domain/share /mnt/cifs --options
sec=krb5i,username=domainuser,domain=AD.DOMAIN

And these are the dmesg logs:

[  374.413601] fs/cifs/cifsfs.c: Devname: //server.domain/share flags: 0
[  374.413627] fs/cifs/connect.c: Domain name set
[  374.413633] No dialect specified on mount. Default has changed to a more
secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less
secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1)
specify vers=1.0 on mount.
[  374.413635] fs/cifs/connect.c: Username: domainuser
[  374.413639] fs/cifs/connect.c: file mode: 0755  dir mode: 0755
[  374.413643] fs/cifs/connect.c: CIFS VFS: in mount_get_conns as Xid: 2 with
uid: 0
[  374.413645] fs/cifs/connect.c: UNC: \\server.domain\share
[  374.413670] fs/cifs/connect.c: Socket created
[  374.413673] fs/cifs/connect.c: sndbuf 16384 rcvbuf 131072 rcvtimeo 0x6d6
[  374.414805] fs/cifs/fscache.c: cifs_fscache_get_client_cookie:
(0x000000001802b6c5/0x00000000a61d46cb)
[  374.414810] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 3 with
uid: 0
[  374.414812] fs/cifs/connect.c: Existing smb sess not found
[  374.414818] fs/cifs/smb2pdu.c: Negotiate protocol
[  374.414840] fs/cifs/transport.c: Sending smb: smb_len=252
[  374.414898] fs/cifs/connect.c: Demultiplex PID: 969
[  374.415589] fs/cifs/connect.c: RFC1002 header 0x134
[  374.415599] fs/cifs/smb2misc.c: SMB2 data length 120 offset 128
[  374.415601] fs/cifs/smb2misc.c: SMB2 len 248
[  374.415603] fs/cifs/smb2misc.c: length of negcontexts 60 pad 0
[  374.415620] fs/cifs/transport.c: cifs_sync_mid_result: cmd=0 mid=0 state=4
[  374.415627] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[  374.415630] fs/cifs/smb2pdu.c: mode 0x1
[  374.415632] fs/cifs/smb2pdu.c: negotiated smb3.1.1 dialect
[  374.415637] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[  374.415640] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
[  374.415642] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
[  374.415644] fs/cifs/asn1.c: OID len = 8 oid = 0x1 0x2 0x348 0x1bb92
[  374.415646] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[  374.415648] fs/cifs/smb2pdu.c: decoding 2 negotiate contexts
[  374.415650] fs/cifs/smb2pdu.c: decode SMB3.11 encryption neg context of len 4
[  374.415652] fs/cifs/smb2pdu.c: SMB311 cipher type:2
[  374.415655] fs/cifs/connect.c: Security Mode: 0x1 Capabilities: 0x300067
TimeAdjust: 0
[  374.415657] fs/cifs/smb2pdu.c: Session Setup
[  374.415659] fs/cifs/smb2pdu.c: sess setup type 5
[  374.415664] fs/cifs/cifs_spnego.c: key description =
ver=0x2;host=server.domain;ip4=xxx.xxx.xxx.xxx;sec=krb5;uid=0x0;creduid=0x0;user
=domainuser;pid=0x3c7
[  374.431889] CIFS VFS: \\server.domain Send error in SessSetup = -126
[  374.431898] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 3)
rc = -126
[  374.431903] fs/cifs/connect.c: build_unc_path_to_root:
full_path=\\server.domain\share
[  374.431906] fs/cifs/connect.c: build_unc_path_to_root:
full_path=\\server.domain\share
[  374.431909] fs/cifs/connect.c: build_unc_path_to_root:
full_path=\\server.domain\share
[  374.431913] fs/cifs/dfs_cache.c: __dfs_cache_find: search path:
\server.domain\share
[  374.431917] fs/cifs/dfs_cache.c: get_dfs_referral: get an DFS referral for
\server.domain\share
[  374.431921] fs/cifs/dfs_cache.c: dfs_cache_noreq_find: path:
\server.domain\share
[  374.431932] fs/cifs/fscache.c: cifs_fscache_release_client_cookie:
(0x000000001802b6c5/0x00000000a61d46cb)
[  374.431944] fs/cifs/connect.c: CIFS VFS: leaving mount_put_conns (xid = 2) rc
= 0
[  374.431946] CIFS VFS: cifs_mount failed w/return code = -2


Best regards

Alberto

On Mon, 2020-03-02 at 13:19 -0300, Paulo Alcantara wrote:
> abrosich@inogs.it writes:
> 
> > I've changed the environment.
> > The linux client now is a Debian machine with testing flavour to have the
> > latest
> > versions of the involved softwares. These are the versions of some of them:
> > 
> > Kernel: #1 SMP Debian 5.4.19-1 (2020-02-13)
> > cifs.upcall: version: 6.9
> > keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
> > sssd: 2.2.3
> > cifs module: 2.23
> 
> I'd guess the following commit would fix your issue:
> 
>     5739375ee423 ("cifs: Fix mount options set in automount")
> 
> but could you please try it with 5.6-rc4?
> 
> Provide full dmesg logs as well.

Re: Permission denied mounting a DFS share with multiuser options

[abrosich]

Hello,
I installed also the latest version of cifs-utils from source but nothing
changed.

Kernel: 5.6.0-rc4
cifs.upcall: version: 6.10
keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
sssd: 2.2.3
cifs module: 2.25

Best regards

Alberto

On Tue, 2020-03-03 at 16:40 +0100, abrosich@inogs.it wrote:
> Hello,
> 
> I installed kernel version 5.6-rc4 but nothing changed.
> 
> This is the command line:
> 
> sudo kinit domainuser
> sudo mount --type cifs --verbose //server.domain/share /mnt/cifs --options
> sec=krb5i,username=domainuser,domain=AD.DOMAIN
> 
> And these are the dmesg logs:
> 
> [  374.413601] fs/cifs/cifsfs.c: Devname: //server.domain/share flags: 0
> [  374.413627] fs/cifs/connect.c: Domain name set
> [  374.413633] No dialect specified on mount. Default has changed to a more
> secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less
> secure SMB1 dialect to access old servers which do not support SMB3 (or
> SMB2.1)
> specify vers=1.0 on mount.
> [  374.413635] fs/cifs/connect.c: Username: domainuser
> [  374.413639] fs/cifs/connect.c: file mode: 0755  dir mode: 0755
> [  374.413643] fs/cifs/connect.c: CIFS VFS: in mount_get_conns as Xid: 2 with
> uid: 0
> [  374.413645] fs/cifs/connect.c: UNC: \\server.domain\share
> [  374.413670] fs/cifs/connect.c: Socket created
> [  374.413673] fs/cifs/connect.c: sndbuf 16384 rcvbuf 131072 rcvtimeo 0x6d6
> [  374.414805] fs/cifs/fscache.c: cifs_fscache_get_client_cookie:
> (0x000000001802b6c5/0x00000000a61d46cb)
> [  374.414810] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 3 with
> uid: 0
> [  374.414812] fs/cifs/connect.c: Existing smb sess not found
> [  374.414818] fs/cifs/smb2pdu.c: Negotiate protocol
> [  374.414840] fs/cifs/transport.c: Sending smb: smb_len=252
> [  374.414898] fs/cifs/connect.c: Demultiplex PID: 969
> [  374.415589] fs/cifs/connect.c: RFC1002 header 0x134
> [  374.415599] fs/cifs/smb2misc.c: SMB2 data length 120 offset 128
> [  374.415601] fs/cifs/smb2misc.c: SMB2 len 248
> [  374.415603] fs/cifs/smb2misc.c: length of negcontexts 60 pad 0
> [  374.415620] fs/cifs/transport.c: cifs_sync_mid_result: cmd=0 mid=0 state=4
> [  374.415627] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
> [  374.415630] fs/cifs/smb2pdu.c: mode 0x1
> [  374.415632] fs/cifs/smb2pdu.c: negotiated smb3.1.1 dialect
> [  374.415637] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> [  374.415640] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> [  374.415642] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
> [  374.415644] fs/cifs/asn1.c: OID len = 8 oid = 0x1 0x2 0x348 0x1bb92
> [  374.415646] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> [  374.415648] fs/cifs/smb2pdu.c: decoding 2 negotiate contexts
> [  374.415650] fs/cifs/smb2pdu.c: decode SMB3.11 encryption neg context of len
> 4
> [  374.415652] fs/cifs/smb2pdu.c: SMB311 cipher type:2
> [  374.415655] fs/cifs/connect.c: Security Mode: 0x1 Capabilities: 0x300067
> TimeAdjust: 0
> [  374.415657] fs/cifs/smb2pdu.c: Session Setup
> [  374.415659] fs/cifs/smb2pdu.c: sess setup type 5
> [  374.415664] fs/cifs/cifs_spnego.c: key description =
> ver=0x2;host=server.domain;ip4=xxx.xxx.xxx.xxx;sec=krb5;uid=0x0;creduid=0x0;us
> er
> =domainuser;pid=0x3c7
> [  374.431889] CIFS VFS: \\server.domain Send error in SessSetup = -126
> [  374.431898] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 3)
> rc = -126
> [  374.431903] fs/cifs/connect.c: build_unc_path_to_root:
> full_path=\\server.domain\share
> [  374.431906] fs/cifs/connect.c: build_unc_path_to_root:
> full_path=\\server.domain\share
> [  374.431909] fs/cifs/connect.c: build_unc_path_to_root:
> full_path=\\server.domain\share
> [  374.431913] fs/cifs/dfs_cache.c: __dfs_cache_find: search path:
> \server.domain\share
> [  374.431917] fs/cifs/dfs_cache.c: get_dfs_referral: get an DFS referral for
> \server.domain\share
> [  374.431921] fs/cifs/dfs_cache.c: dfs_cache_noreq_find: path:
> \server.domain\share
> [  374.431932] fs/cifs/fscache.c: cifs_fscache_release_client_cookie:
> (0x000000001802b6c5/0x00000000a61d46cb)
> [  374.431944] fs/cifs/connect.c: CIFS VFS: leaving mount_put_conns (xid = 2)
> rc
> = 0
> [  374.431946] CIFS VFS: cifs_mount failed w/return code = -2
> 
> 
> Best regards
> 
> Alberto
> 
> On Mon, 2020-03-02 at 13:19 -0300, Paulo Alcantara wrote:
> > abrosich@inogs.it writes:
> > 
> > > I've changed the environment.
> > > The linux client now is a Debian machine with testing flavour to have the
> > > latest
> > > versions of the involved softwares. These are the versions of some of
> > > them:
> > > 
> > > Kernel: #1 SMP Debian 5.4.19-1 (2020-02-13)
> > > cifs.upcall: version: 6.9
> > > keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
> > > sssd: 2.2.3
> > > cifs module: 2.23
> > 
> > I'd guess the following commit would fix your issue:
> > 
> >     5739375ee423 ("cifs: Fix mount options set in automount")
> > 
> > but could you please try it with 5.6-rc4?
> > 
> > Provide full dmesg logs as well.

Re: Permission denied mounting a DFS share with multiuser options

[Steve French]

The first thing I would look at for a problem like this is what
kerberos ticket you are using.

The username and domain on the mount command shouldn't matter much
since you are using kerberos tickets not ntlmv2/ntmssp.  The request
key upcall will typically look in the key cache for the kerberos
ticket for the user running the current process (usually root).  One
common problem is that user's ssh into the system but it doesn't get
them a krb5 ticket in the expected location due to the kerberos client
library they are using (you can use the klist command e.g. "klist -a"
to display additional information) or another common problem is that
the user sshs into the system but then mounts while running as a
different user (usually root) so it can't find the kerberos ticket
that root got (you can do a "kinit" as root to get one to workaround
this.

Sachin has a blog entry that can be useful:
http://sprabhu.blogspot.com/2014/12/debugging-calls-to-cifsupcall.html

On Wed, Mar 4, 2020 at 3:18 AM <abrosich@inogs.it> wrote:
>
>
> Hello,
> I installed also the latest version of cifs-utils from source but nothing
> changed.
>
> Kernel: 5.6.0-rc4
> cifs.upcall: version: 6.10
> keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
> sssd: 2.2.3
> cifs module: 2.25
>
> Best regards
>
> Alberto
>
> On Tue, 2020-03-03 at 16:40 +0100, abrosich@inogs.it wrote:
> > Hello,
> >
> > I installed kernel version 5.6-rc4 but nothing changed.
> >
> > This is the command line:
> >
> > sudo kinit domainuser
> > sudo mount --type cifs --verbose //server.domain/share /mnt/cifs --options
> > sec=krb5i,username=domainuser,domain=AD.DOMAIN
> >
> > And these are the dmesg logs:
> >
> > [  374.413601] fs/cifs/cifsfs.c: Devname: //server.domain/share flags: 0
> > [  374.413627] fs/cifs/connect.c: Domain name set
> > [  374.413633] No dialect specified on mount. Default has changed to a more
> > secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less
> > secure SMB1 dialect to access old servers which do not support SMB3 (or
> > SMB2.1)
> > specify vers=1.0 on mount.
> > [  374.413635] fs/cifs/connect.c: Username: domainuser
> > [  374.413639] fs/cifs/connect.c: file mode: 0755  dir mode: 0755
> > [  374.413643] fs/cifs/connect.c: CIFS VFS: in mount_get_conns as Xid: 2 with
> > uid: 0
> > [  374.413645] fs/cifs/connect.c: UNC: \\server.domain\share
> > [  374.413670] fs/cifs/connect.c: Socket created
> > [  374.413673] fs/cifs/connect.c: sndbuf 16384 rcvbuf 131072 rcvtimeo 0x6d6
> > [  374.414805] fs/cifs/fscache.c: cifs_fscache_get_client_cookie:
> > (0x000000001802b6c5/0x00000000a61d46cb)
> > [  374.414810] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 3 with
> > uid: 0
> > [  374.414812] fs/cifs/connect.c: Existing smb sess not found
> > [  374.414818] fs/cifs/smb2pdu.c: Negotiate protocol
> > [  374.414840] fs/cifs/transport.c: Sending smb: smb_len=252
> > [  374.414898] fs/cifs/connect.c: Demultiplex PID: 969
> > [  374.415589] fs/cifs/connect.c: RFC1002 header 0x134
> > [  374.415599] fs/cifs/smb2misc.c: SMB2 data length 120 offset 128
> > [  374.415601] fs/cifs/smb2misc.c: SMB2 len 248
> > [  374.415603] fs/cifs/smb2misc.c: length of negcontexts 60 pad 0
> > [  374.415620] fs/cifs/transport.c: cifs_sync_mid_result: cmd=0 mid=0 state=4
> > [  374.415627] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
> > [  374.415630] fs/cifs/smb2pdu.c: mode 0x1
> > [  374.415632] fs/cifs/smb2pdu.c: negotiated smb3.1.1 dialect
> > [  374.415637] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> > [  374.415640] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> > [  374.415642] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
> > [  374.415644] fs/cifs/asn1.c: OID len = 8 oid = 0x1 0x2 0x348 0x1bb92
> > [  374.415646] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> > [  374.415648] fs/cifs/smb2pdu.c: decoding 2 negotiate contexts
> > [  374.415650] fs/cifs/smb2pdu.c: decode SMB3.11 encryption neg context of len
> > 4
> > [  374.415652] fs/cifs/smb2pdu.c: SMB311 cipher type:2
> > [  374.415655] fs/cifs/connect.c: Security Mode: 0x1 Capabilities: 0x300067
> > TimeAdjust: 0
> > [  374.415657] fs/cifs/smb2pdu.c: Session Setup
> > [  374.415659] fs/cifs/smb2pdu.c: sess setup type 5
> > [  374.415664] fs/cifs/cifs_spnego.c: key description =
> > ver=0x2;host=server.domain;ip4=xxx.xxx.xxx.xxx;sec=krb5;uid=0x0;creduid=0x0;us
> > er
> > =domainuser;pid=0x3c7
> > [  374.431889] CIFS VFS: \\server.domain Send error in SessSetup = -126
> > [  374.431898] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 3)
> > rc = -126
> > [  374.431903] fs/cifs/connect.c: build_unc_path_to_root:
> > full_path=\\server.domain\share
> > [  374.431906] fs/cifs/connect.c: build_unc_path_to_root:
> > full_path=\\server.domain\share
> > [  374.431909] fs/cifs/connect.c: build_unc_path_to_root:
> > full_path=\\server.domain\share
> > [  374.431913] fs/cifs/dfs_cache.c: __dfs_cache_find: search path:
> > \server.domain\share
> > [  374.431917] fs/cifs/dfs_cache.c: get_dfs_referral: get an DFS referral for
> > \server.domain\share
> > [  374.431921] fs/cifs/dfs_cache.c: dfs_cache_noreq_find: path:
> > \server.domain\share
> > [  374.431932] fs/cifs/fscache.c: cifs_fscache_release_client_cookie:
> > (0x000000001802b6c5/0x00000000a61d46cb)
> > [  374.431944] fs/cifs/connect.c: CIFS VFS: leaving mount_put_conns (xid = 2)
> > rc
> > = 0
> > [  374.431946] CIFS VFS: cifs_mount failed w/return code = -2
> >
> >
> > Best regards
> >
> > Alberto
> >
> > On Mon, 2020-03-02 at 13:19 -0300, Paulo Alcantara wrote:
> > > abrosich@inogs.it writes:
> > >
> > > > I've changed the environment.
> > > > The linux client now is a Debian machine with testing flavour to have the
> > > > latest
> > > > versions of the involved softwares. These are the versions of some of
> > > > them:
> > > >
> > > > Kernel: #1 SMP Debian 5.4.19-1 (2020-02-13)
> > > > cifs.upcall: version: 6.9
> > > > keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
> > > > sssd: 2.2.3
> > > > cifs module: 2.23
> > >
> > > I'd guess the following commit would fix your issue:
> > >
> > >     5739375ee423 ("cifs: Fix mount options set in automount")
> > >
> > > but could you please try it with 5.6-rc4?
> > >
> > > Provide full dmesg logs as well.
>


-- 
Thanks,

Steve

Re: Permission denied mounting a DFS share with multiuser options

[abrosich]

Hello,
I always tried as root, using sudo.
I'm trying using a domain administrator accout. In production I will use (if it
will work) using an SPN.
I obtain a ticket using kinit and I can see it with klist.

The problem is surely with kerberos and cifs.upcall used together, because:

- using "smbclient -k -U domainuser -W AD.DOMAIN" I can connect and browse the
share without password

- using "mount -t cifs" without "sec=krb5" works, after asking for the password


These are the errors in /var/log/debug

Mar  5 15:33:19 linws003 cifs.upcall: get_existing_cc: default ccache is
FILE:/tmp/krb5cc_0
Mar  5 15:33:19 linws003 cifs.upcall: handle_krb5_mech: getting service ticket
for server.domain
Mar  5 15:33:19 linws003 cifs.upcall: cifs_krb5_get_req: unable to get
credentials for server.domain
Mar  5 15:33:19 linws003 cifs.upcall: handle_krb5_mech: failed to obtain service
ticket (-1765328377)
Mar  5 15:33:19 linws003 cifs.upcall: Unable to obtain service ticket
Mar  5 15:33:19 linws003 cifs.upcall: Exit status -1765328377

The cache file /tmp/krb5cc_0 exists. I can see the content with klist and it is
correct.

Tracing the call of cifs.upcall the only errors I can find are:

7295  15:33:19 openat(AT_FDCWD, "/var/lib/sss/pubconf/kpasswdinfo.AD.DOMAIN",
O_RDONLY) = -1 ENOENT (No such file or directory)
7295  15:33:19 sendto(3, "<31>Mar  5 15:33:19 cifs.upcall: cifs_krb5_get_req:
unable to get credentials for server.domain", 100, MSG_NOSIGNAL, NULL, 0) = 100
7295  15:33:19 sendto(3, "<31>Mar  5 15:33:19 cifs.upcall: handle_krb5_mech:
failed to obtain service ticket (-1765328377)", 96, MSG_NOSIGNAL, NULL, 0) = 96
7295  15:33:19 sendto(3, "<31>Mar  5 15:33:19 cifs.upcall: Unable to obtain
service ticket", 64, MSG_NOSIGNAL, NULL, 0) = 64
7295  15:33:19 sendto(3, "<31>Mar  5 15:33:19 cifs.upcall: Exit status
-1765328377", 56, MSG_NOSIGNAL, NULL, 0) = 56

I don't know if the absence of the file
/var/lib/sss/pubconf/kpasswdinfo.AD.DOMAIN is the cause of the following errors.

What I'm doing wrong?

Best regards

Alberto

On Wed, 2020-03-04 at 15:11 -0600, Steve French wrote:
> The first thing I would look at for a problem like this is what
> kerberos ticket you are using.
> 
> The username and domain on the mount command shouldn't matter much
> since you are using kerberos tickets not ntlmv2/ntmssp.  The request
> key upcall will typically look in the key cache for the kerberos
> ticket for the user running the current process (usually root).  One
> common problem is that user's ssh into the system but it doesn't get
> them a krb5 ticket in the expected location due to the kerberos client
> library they are using (you can use the klist command e.g. "klist -a"
> to display additional information) or another common problem is that
> the user sshs into the system but then mounts while running as a
> different user (usually root) so it can't find the kerberos ticket
> that root got (you can do a "kinit" as root to get one to workaround
> this.
> 
> Sachin has a blog entry that can be useful:
> http://sprabhu.blogspot.com/2014/12/debugging-calls-to-cifsupcall.html
> 
> On Wed, Mar 4, 2020 at 3:18 AM <abrosich@inogs.it> wrote:
> > 
> > Hello,
> > I installed also the latest version of cifs-utils from source but nothing
> > changed.
> > 
> > Kernel: 5.6.0-rc4
> > cifs.upcall: version: 6.10
> > keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
> > sssd: 2.2.3
> > cifs module: 2.25
> > 
> > Best regards
> > 
> > Alberto
> > 
> > On Tue, 2020-03-03 at 16:40 +0100, abrosich@inogs.it wrote:
> > > Hello,
> > > 
> > > I installed kernel version 5.6-rc4 but nothing changed.
> > > 
> > > This is the command line:
> > > 
> > > sudo kinit domainuser
> > > sudo mount --type cifs --verbose //server.domain/share /mnt/cifs --options
> > > sec=krb5i,username=domainuser,domain=AD.DOMAIN
> > > 
> > > And these are the dmesg logs:
> > > 
> > > [  374.413601] fs/cifs/cifsfs.c: Devname: //server.domain/share flags: 0
> > > [  374.413627] fs/cifs/connect.c: Domain name set
> > > [  374.413633] No dialect specified on mount. Default has changed to a
> > > more
> > > secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the
> > > less
> > > secure SMB1 dialect to access old servers which do not support SMB3 (or
> > > SMB2.1)
> > > specify vers=1.0 on mount.
> > > [  374.413635] fs/cifs/connect.c: Username: domainuser
> > > [  374.413639] fs/cifs/connect.c: file mode: 0755  dir mode: 0755
> > > [  374.413643] fs/cifs/connect.c: CIFS VFS: in mount_get_conns as Xid: 2
> > > with
> > > uid: 0
> > > [  374.413645] fs/cifs/connect.c: UNC: \\server.domain\share
> > > [  374.413670] fs/cifs/connect.c: Socket created
> > > [  374.413673] fs/cifs/connect.c: sndbuf 16384 rcvbuf 131072 rcvtimeo
> > > 0x6d6
> > > [  374.414805] fs/cifs/fscache.c: cifs_fscache_get_client_cookie:
> > > (0x000000001802b6c5/0x00000000a61d46cb)
> > > [  374.414810] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 3
> > > with
> > > uid: 0
> > > [  374.414812] fs/cifs/connect.c: Existing smb sess not found
> > > [  374.414818] fs/cifs/smb2pdu.c: Negotiate protocol
> > > [  374.414840] fs/cifs/transport.c: Sending smb: smb_len=252
> > > [  374.414898] fs/cifs/connect.c: Demultiplex PID: 969
> > > [  374.415589] fs/cifs/connect.c: RFC1002 header 0x134
> > > [  374.415599] fs/cifs/smb2misc.c: SMB2 data length 120 offset 128
> > > [  374.415601] fs/cifs/smb2misc.c: SMB2 len 248
> > > [  374.415603] fs/cifs/smb2misc.c: length of negcontexts 60 pad 0
> > > [  374.415620] fs/cifs/transport.c: cifs_sync_mid_result: cmd=0 mid=0
> > > state=4
> > > [  374.415627] fs/cifs/misc.c: Null buffer passed to
> > > cifs_small_buf_release
> > > [  374.415630] fs/cifs/smb2pdu.c: mode 0x1
> > > [  374.415632] fs/cifs/smb2pdu.c: negotiated smb3.1.1 dialect
> > > [  374.415637] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> > > [  374.415640] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> > > [  374.415642] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
> > > [  374.415644] fs/cifs/asn1.c: OID len = 8 oid = 0x1 0x2 0x348 0x1bb92
> > > [  374.415646] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> > > [  374.415648] fs/cifs/smb2pdu.c: decoding 2 negotiate contexts
> > > [  374.415650] fs/cifs/smb2pdu.c: decode SMB3.11 encryption neg context of
> > > len
> > > 4
> > > [  374.415652] fs/cifs/smb2pdu.c: SMB311 cipher type:2
> > > [  374.415655] fs/cifs/connect.c: Security Mode: 0x1 Capabilities:
> > > 0x300067
> > > TimeAdjust: 0
> > > [  374.415657] fs/cifs/smb2pdu.c: Session Setup
> > > [  374.415659] fs/cifs/smb2pdu.c: sess setup type 5
> > > [  374.415664] fs/cifs/cifs_spnego.c: key description =
> > > ver=0x2;host=server.domain;ip4=xxx.xxx.xxx.xxx;sec=krb5;uid=0x0;creduid=0x
> > > 0;us
> > > er
> > > =domainuser;pid=0x3c7
> > > [  374.431889] CIFS VFS: \\server.domain Send error in SessSetup = -126
> > > [  374.431898] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid
> > > = 3)
> > > rc = -126
> > > [  374.431903] fs/cifs/connect.c: build_unc_path_to_root:
> > > full_path=\\server.domain\share
> > > [  374.431906] fs/cifs/connect.c: build_unc_path_to_root:
> > > full_path=\\server.domain\share
> > > [  374.431909] fs/cifs/connect.c: build_unc_path_to_root:
> > > full_path=\\server.domain\share
> > > [  374.431913] fs/cifs/dfs_cache.c: __dfs_cache_find: search path:
> > > \server.domain\share
> > > [  374.431917] fs/cifs/dfs_cache.c: get_dfs_referral: get an DFS referral
> > > for
> > > \server.domain\share
> > > [  374.431921] fs/cifs/dfs_cache.c: dfs_cache_noreq_find: path:
> > > \server.domain\share
> > > [  374.431932] fs/cifs/fscache.c: cifs_fscache_release_client_cookie:
> > > (0x000000001802b6c5/0x00000000a61d46cb)
> > > [  374.431944] fs/cifs/connect.c: CIFS VFS: leaving mount_put_conns (xid =
> > > 2)
> > > rc
> > > = 0
> > > [  374.431946] CIFS VFS: cifs_mount failed w/return code = -2
> > > 
> > > 
> > > Best regards
> > > 
> > > Alberto
> > > 
> > > On Mon, 2020-03-02 at 13:19 -0300, Paulo Alcantara wrote:
> > > > abrosich@inogs.it writes:
> > > > 
> > > > > I've changed the environment.
> > > > > The linux client now is a Debian machine with testing flavour to have
> > > > > the
> > > > > latest
> > > > > versions of the involved softwares. These are the versions of some of
> > > > > them:
> > > > > 
> > > > > Kernel: #1 SMP Debian 5.4.19-1 (2020-02-13)
> > > > > cifs.upcall: version: 6.9
> > > > > keyutils: keyctl from keyutils-1.6.1 (Built 2020-02-10)
> > > > > sssd: 2.2.3
> > > > > cifs module: 2.23
> > > > 
> > > > I'd guess the following commit would fix your issue:
> > > > 
> > > >     5739375ee423 ("cifs: Fix mount options set in automount")
> > > > 
> > > > but could you please try it with 5.6-rc4?
> > > > 
> > > > Provide full dmesg logs as well.
> 
>