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@xxxxxxxx> 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@xxxxxxxx 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@xxxxxxxx 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. > >
