-
Bug
-
Resolution: Done
-
Undefined
-
None
-
rhel-8.9.0
-
None
-
None
-
None
-
rhel-sst-idm-sssd
-
ssg_idm
-
0
-
False
-
-
None
-
Red Hat Enterprise Linux
-
None
-
None
-
None
-
None
Problem description from user:
Trying to use gio (Nautilus) to mount a SMB share as normal user fails:
$ gio mount smb://scratch0/scratch
gio: smb://scratch0/scratch/: Failed to mount Windows share: Cannot allocate memory
Trying the same as user root with a normal mount works:
$ sudo mount -t cifs -o multiuser,sec=krb5 //scratch01/scratch /mnt [buchel_k@lxdev05 ~]$ ls -l /mnt
total 4
drwxr-xr-x 2 user group 0 Dec 5 05:00 FOO
drwxr-xr-x 2 user group 0 Oct 30 05:00 BAR
...
And as you see there is a working Kerberos setup:
$ klist
Ticket cache: KCM:44951:desktop
Default principal: user@HOST
Valid starting Expires Service principal
12/15/2023 08:20:34 12/15/2023 18:20:34 krbtgt/FOO@BAR
renew until 12/22/2023 08:20:34
12/15/2023 08:24:05 12/15/2023 18:20:34 cifs/scratch01@
renew until 12/22/2023 08:20:34
Ticket server: cifs/scratch01@HOST
Define the value or impact to you or the business RHEL Desktop users cannot easily access their windows shares.
Customer tried debugging with and generated gvfsd.log
KRB5_TRACE=/dev/stdout GVFS_SMB_DEBUG=10 GVFS_DEBUG=1 $(find /usr/lib* -name gvfsd 2>/dev/null) --replace 2>&1 | tee gvfsd.log
and a second attempt with the fully qualified domain name of the windows server and there the behavior was different: Kerberos still failed, but there was a fallback to ask the password, after the mount was working. The log output you find also attached as
gvfsd_fqdn.log
Basically customer wants to automate the mount with kerberos ticket, and avoid asking for a password.
Do you have some suggestion on possible correction to the problem, or what to ask to further debug the issue?
