* Permission denied mounting a DFS share with multiuser options @ 2019-11-27 12:20 abrosich 2019-12-03 22:16 ` Steve French 0 siblings, 1 reply; 8+ messages in thread From: abrosich @ 2019-11-27 12:20 UTC (permalink / raw) To: linux-cifs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Permission denied mounting a DFS share with multiuser options 2019-11-27 12:20 Permission denied mounting a DFS share with multiuser options abrosich @ 2019-12-03 22:16 ` Steve French 2020-03-02 14:11 ` abrosich 0 siblings, 1 reply; 8+ messages in thread From: Steve French @ 2019-12-03 22:16 UTC (permalink / raw) To: abrosich; +Cc: CIFS 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Permission denied mounting a DFS share with multiuser options 2019-12-03 22:16 ` Steve French @ 2020-03-02 14:11 ` abrosich 2020-03-02 16:19 ` Paulo Alcantara 0 siblings, 1 reply; 8+ messages in thread From: abrosich @ 2020-03-02 14:11 UTC (permalink / raw) To: CIFS 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 > > > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Permission denied mounting a DFS share with multiuser options 2020-03-02 14:11 ` abrosich @ 2020-03-02 16:19 ` Paulo Alcantara 2020-03-03 15:40 ` abrosich 0 siblings, 1 reply; 8+ messages in thread From: Paulo Alcantara @ 2020-03-02 16:19 UTC (permalink / raw) To: abrosich, CIFS 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Permission denied mounting a DFS share with multiuser options 2020-03-02 16:19 ` Paulo Alcantara @ 2020-03-03 15:40 ` abrosich 2020-03-04 9:17 ` abrosich 0 siblings, 1 reply; 8+ messages in thread From: abrosich @ 2020-03-03 15:40 UTC (permalink / raw) To: Paulo Alcantara, CIFS 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Permission denied mounting a DFS share with multiuser options 2020-03-03 15:40 ` abrosich @ 2020-03-04 9:17 ` abrosich 2020-03-04 21:11 ` Steve French 0 siblings, 1 reply; 8+ messages in thread From: abrosich @ 2020-03-04 9:17 UTC (permalink / raw) To: CIFS 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Permission denied mounting a DFS share with multiuser options 2020-03-04 9:17 ` abrosich @ 2020-03-04 21:11 ` Steve French 2020-03-05 15:07 ` abrosich 0 siblings, 1 reply; 8+ messages in thread From: Steve French @ 2020-03-04 21:11 UTC (permalink / raw) To: abrosich; +Cc: CIFS 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Permission denied mounting a DFS share with multiuser options 2020-03-04 21:11 ` Steve French @ 2020-03-05 15:07 ` abrosich 0 siblings, 0 replies; 8+ messages in thread From: abrosich @ 2020-03-05 15:07 UTC (permalink / raw) To: CIFS 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. > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-03-05 15:08 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-27 12:20 Permission denied mounting a DFS share with multiuser options abrosich 2019-12-03 22:16 ` Steve French 2020-03-02 14:11 ` abrosich 2020-03-02 16:19 ` Paulo Alcantara 2020-03-03 15:40 ` abrosich 2020-03-04 9:17 ` abrosich 2020-03-04 21:11 ` Steve French 2020-03-05 15:07 ` abrosich
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).