nautilus accessing samba shares doesn't use cached credentials

Bug #1771943 reported by piviul
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gvfs (Ubuntu)
Fix Committed
Low
Unassigned

Bug Description

I don't know if the bug is in nautilus or other package but accessing samba shares in a samba domain membership authentication using winbind, nautilus doesn't try to use cached credentials to access network shares.
Before the upgrade to ubuntu bionic (18.04) all works as expected.

I have configured winbind bind module for samba authentication on a samba server and all seems works flawless. I have enabled winbind offline logon (in smb.conf) and cached credentials (in /etc/security/pam_winbind.conf). Offline logon seems to work but when I access samba shares, nautilus ask me for a username and password even if I log on using a valid domain account and this valid account can access the samba share.

If you need some more info please ask me

Have a great day

Piviul

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nautilus 1:3.26.3-0ubuntu4
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic i686
NonfreeKernelModules: nvidia wl
ApportVersion: 2.20.9-0ubuntu7
Architecture: i386
CurrentDesktop: ubuntu:GNOME
Date: Fri May 18 08:19:06 2018
GsettingsChanges:
 b'org.gnome.nautilus.window-state' b'geometry' b"'855x550+65+24'"
 b'org.gnome.nautilus.window-state' b'maximized' b'true'
InstallationDate: Installed on 2012-05-17 (2191 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
UpgradeStatus: Upgraded to bionic on 2018-05-03 (15 days ago)
usr_lib_nautilus:

Revision history for this message
piviul (piviul) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, could you give details on how the mounts are done? Is that accessing smb:// urls in nautilus/gvfs or do you mount the share by other means? could you add your journalctl log from a session where you triggered the issue?

Changed in nautilus (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
piviul (piviul) wrote :

Hi Sebastien, thank you very much to spend your time to try solve this bug...

The mount is performed browsing the network and selecting a server but the same happens if write directly in the nautilus address bar an address like smb://servername/sharename

If I launch in a terminal the command journalctl -f nothing is logged when I try to connect a samba share. If I have to enable some flag to have a verbose log please let me know.

Piviul

Revision history for this message
Sebastien Bacher (seb128) wrote :

what happens if you "gio mount <url>"?

Also can you do 'GVFS_DEBUG=1 /usr/lib/gvfs/gvfsd -r' before trying the mount and past the output you get on the service?

Revision history for this message
piviul (piviul) wrote :

$ LANG=C; gio mount //server/share
gio: file:////server/share: volume doesn?t implement mount

$ GVFS_DEBUG=1 /usr/lib/gvfs/gvfsd -r

trash: Added new job source 0x559cf2cf28b0 (GVfsBackendTrash)
trash: Queued new job 0x559cf2cf3840 (GVfsJobMount)
trash: send_reply(0x559cf2cf3840), failed=0 ()
trash: backend_dbus_handler org.gtk.vfs.Mount:CreateFileMonitor (pid=2250)
trash: Queued new job 0x559cf2cf3ba0 (GVfsJobCreateMonitor)
trash: send_reply(0x559cf2cf3ba0), failed=0 ()
trash: backend_dbus_handler org.gtk.vfs.Mount:CreateFileMonitor (pid=2250)
trash: Queued new job 0x559cf2cf3ba0 (GVfsJobCreateMonitor)
trash: send_reply(0x559cf2cf3ba0), failed=0 ()
trash: backend_dbus_handler org.gtk.vfs.Mount:QueryInfo (pid=2250)
trash: Queued new job 0x559cf2cde370 (GVfsJobQueryInfo)
trash: send_reply(0x559cf2cde370), failed=0 ()
trash: backend_dbus_handler org.gtk.vfs.Mount:QueryInfo (pid=2250)
trash: Queued new job 0x559cf2cde410 (GVfsJobQueryInfo)
trash: send_reply(0x559cf2cde410), failed=0 ()
smb: g_vfs_backend_smb_init: default workgroup = 'NULL'
smb: Added new job source 0x5617d9cfe130 (GVfsBackendSmb)
smb: Queued new job 0x5617d9cff9d0 (GVfsJobMount)
smb: do_mount - URI = smb://server/share
smb: do_mount - try #0
smb: auth_callback - kerberos pass
smb: auth_callback - out: last_user = 'username', last_domain = 'DOMAIN'
smb: do_mount - [smb://server/share; 0] res = -1, cancelled = 0, errno = [1] 'Operation not permitted'
smb: do_mount - after anon, enabling NTLMSSP fallback
smb: do_mount - try #1
smb: auth_callback - normal pass
smb: auth_callback - asking for password...
smb: auth_callback - out: last_user = 'ABORT', last_domain = 'DOMAIN'
smb: do_mount - [smb://server/share; 1] res = -1, cancelled = 1, errno = [1] 'Operation not permitted'
smb: do_mount - (errno != EPERM && errno != EACCES), cancelled = 1, breaking
smb: send_reply(0x5617d9cff9d0), failed=1 (Password dialog cancelled)

Probably for an excess of privacy, I have replaced in the logs the username, server, domain and share name. If you find some incoherence please let me know and I send you the original log without any substitution.

Thank you very much!

Piviul

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for the extra info, one problem though

> $ LANG=C; gio mount //server/share
> gio: file:////server/share: volume doesn?t implement mount

the url should be prefixed with the share type as in nautilus, so it's probably "smb://server/share" in your case

Revision history for this message
piviul (piviul) wrote : Re: [Bug 1771943] Re: nautilus accessing samba shares doesn't use cached credentials

Il 30/01/19 14:10, Sebastien Bacher ha scritto:
> Thanks for the extra info, one problem though
>
>> $ LANG=C; gio mount //server/share
>> gio: file:////server/share: volume doesn?t implement mount
>
> the url should be prefixed with the share type as in nautilus, so it's
> probably "smb://server/share" in your case

the command
$ gio mount //server/share

ask me user, domain and password. If for each question i press return (I
don't enter username neither domain neither password) the share is
mounted correctly exactly as I was entering the current username, domain
and password. In other word seems that gio use the cached credential...

I can't understand but this is the result.

Piviul

Revision history for this message
Sebastien Bacher (seb128) wrote :

> the command
> $ gio mount //server/share

> ask me user, domain and password.

you mean "smb://server/share"? because your previous paste was "gio: file:////server/share: volume doesn?t implement mount" or does it ask for credential after logging that error?

If you did get a different behaviour when using smb://... could you get the GVFS_DEBUG=1 gvfsd -r log again?

Revision history for this message
piviul (piviul) wrote :

Il 30/01/19 17:17, Sebastien Bacher ha scritto:
>> the command
>> $ gio mount //server/share
>
>> ask me user, domain and password.
>
> you mean "smb://server/share"? because your previous paste was "gio:
> file:////server/share: volume doesn?t implement mount" or does it ask
> for credential after logging that error?
yes of course, I'm sorry, I mean smb://server/share!!!

Ok, so I have launched the command:
$ LANG=C; gio mount smb://server/share

Ask for username, domain and password. I have only press return when ask
for username, domain and password and the share has been mounted and
these are the logs of "GVFS_DEBUG=1 gvfsd -r log":

smb: g_vfs_backend_smb_init: default workgroup = 'NULL'
smb: Added new job source 0x55a984abf130 (GVfsBackendSmb)
smb: Queued new job 0x55a984ac09d0 (GVfsJobMount)
smb: do_mount - URI = smb://server/share
smb: do_mount - try #0
smb: auth_callback - kerberos pass
smb: auth_callback - out: last_user = 'DOMAIN\username', last_domain =
'DOMAIN'
smb: do_mount - [smb://server/share; 0] res = -1, cancelled = 0, errno =
[1] 'Operazione non permessa'
smb: do_mount - after anon, enabling NTLMSSP fallback
smb: do_mount - try #1
smb: auth_callback - normal pass
smb: auth_callback - asking for password...
smb: auth_callback - out: last_user = 'DOMAIN\username', last_domain =
'DOMAIN'
smb: do_mount - [smb://server/share; 1] res = 0, cancelled = 0, errno =
[17] 'File già esistente'
smb: do_mount - login successful
smb: send_reply(0x55a984ac09d0), failed=0 ()

Thank you very much!

Piviul

Changed in nautilus (Ubuntu):
status: Incomplete → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks, I've send the report and the debug info upstream let's sse if they have a better idea about the problem
https://gitlab.gnome.org/GNOME/nautilus/issues/864

Changed in nautilus (Ubuntu):
status: New → Triaged
Revision history for this message
Sebastien Bacher (seb128) wrote :

The issue got reassigned to the gvfs backend
https://gitlab.gnome.org/GNOME/gvfs/issues/369

affects: nautilus (Ubuntu) → gvfs (Ubuntu)
Revision history for this message
Sebastien Bacher (seb128) wrote :

Upstream comment

'SMB backend doesn't use smbc_setOptionUseCCache explicitly in order to enable winbind ccache, but it seems that it is enabled by default, at least on my system. Please try to obtain the debug log again, but also with GVFS_SMB_DEBUG=3. The SMB backend is based on libsmbclient, so please also verify whether smbclient works and provide its debug log. Tentatively something like smbclient //server/share --debuglevel 3 --kerberos --use-ccache --user ... --workgroup ... should work.'

Revision history for this message
piviul (piviul) wrote :
Download full text (6.5 KiB)

Il 31/01/19 14:31, Sebastien Bacher ha scritto:
> Upstream comment
>
> 'SMB backend doesn't use smbc_setOptionUseCCache explicitly in order to
> enable winbind ccache, but it seems that it is enabled by default, at
> least on my system. Please try to obtain the debug log again, but also
> with GVFS_SMB_DEBUG=3.

If I have well understood this is the output:
$ GVFS_DEBUG=1 GVFS_SMB_DEBUG=3 /usr/lib/gvfs/gvfsd -r
smb: g_vfs_backend_smb_init: default workgroup = 'NULL'
smb: Added new job source 0x562f1e60d130 (GVfsBackendSmb)
smb: Queued new job 0x562f1e60e1d0 (GVfsJobMount)
Using netbios name 103NOTE0512.
Using workgroup DOMAIN.
smb: do_mount - URI = smb://server/share
smb: do_mount - try #0
smb: auth_callback - kerberos pass
smb: auth_callback - out: last_user = 'DOMAIN\username', last_domain =
'DOMAIN'
tdb(/var/cache/samba/gencache.tdb): tdb_open_ex: could not open file
/var/cache/samba/gencache.tdb: Permesso negato
resolve_lmhosts: Attempting lmhosts lookup for name server<0x20>
resolve_wins: WINS server resolution selected and no WINS servers listed.
resolve_hosts: Attempting host lookup for name server<0x20>
Connecting to 192.168.70.5 at port 445
got OID=1.3.6.1.4.1.311.2.2.10
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
SPNEGO: Could not find a suitable mechtype in NEG_TOKEN_INIT
SPNEGO login failed: An invalid parameter was passed to a service or
function.
smb: do_mount - [smb://server/share; 0] res = -1, cancelled = 0, errno =
[1] 'Operazione non permessa'
smb: do_mount - after anon, enabling NTLMSSP fallback
smb: do_mount - try #1
smb: auth_callback - normal pass
smb: auth_callback - asking for password...
smb: auth_callback - out: last_user = 'DOMAIN\username', last_domain =
'DOMAIN'
resolve_lmhosts: Attempting lmhosts lookup for name server<0x20>
resolve_wins: WINS server resolution selected and no WINS servers listed.
resolve_hosts: Attempting host lookup for name server<0x20>
Connecting to 192.168.70.5 at port 445
got OID=1.3.6.1.4.1.311.2.2.10
Got challenge flags:
Got NTLMSSP neg_flags=0x62898215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62088215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62088215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62088215
Server connect ok: //server/share: 0x7f583c026c90
smb: do_mount - [smb://server/share; 1] res = 0, cancelled = 0, errno =
[17] 'File già esistente'
smb: do_mount - login successful
smb: send_reply(0x562f1e60e1d0), failed=0 ()

> The SMB backend is based on libsmbclient, so
> please also verify whether smbclient works and provide its debug log.
> Tentatively something like smbclient //server/share --debuglevel 3
> --kerberos --use-ccache --user ....

Read more...

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks, I've sent the info upstream

Google for the error it's mentioned in some forum/reports like https://lists.samba.org/archive/samba/2018-April/215021.html but that doesn't help much...

Revision history for this message
piviul (piviul) wrote :

But I don't use kerberos, I use winbind to have domain membership authentication! smbclient seems to works perfectly with cached credential if I remove the optional parameter --kerberos... but why gvfs doesn't it?

Piviul

Revision history for this message
piviul (piviul) wrote :

Il 12/02/19 20:38, Andreas Hasenack ha scritto:> [...]
> I found some bugs in debian and upstream, still open, but in a
> "needinfo" state.
do you mean the bug https://bugzilla.samba.org/show_bug.cgi?id=10455?

I have forgot this bug and I'm the one that open it: AAARGH!

Any way changing /etc/pam.d/common-auth from
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
to
auth [success=1 default=ignore] pam_winbind.so cached_login try_first_pass

as suggested by David Pinheiro seems to solve the problem.

Thank you very much indeed. Now I try to resume the upstream bug I have opened in samba.

Piviul

Revision history for this message
piviul (piviul) wrote :

I'm sorry for the comment #16, I have wrong the bug id! If anyone can remove it...

Piviul

Revision history for this message
Sebastien Bacher (seb128) wrote :

Upstream comment

'smbc_new_context() calls smbc_setOptionUseCCache(context, True) if LIBSMBCLIENT_NO_CCACHE environemnt variable is not defined. I suppose it is not defined in your system, but can you please confirm it?

smbclient --kerberos --use-ccache doesn't work as it forces kerberos to be used, however gvfs uses smbc_setOptionFallbackAfterKerberos (op_backend->smb_context, 1), which I suppose should fallback to ccache as well. It would be nice to confirm that downgrade of samba/gvfs package solves the problem, to figure out where is the regression.

In theory, we could break something by the commit a0aec329, but it is 4 years old.

I am not sure how exactly is ccache authentication handled, but first iteration uses smbc_setOptionFallbackAfterKerberos (smb_context, op_backend->user != NULL). I wonder if it helps to specify the username in the URI, e.g. gio mount smb://username@server/share?'

Revision history for this message
piviul (piviul) wrote :

Il 14/02/19 11:20, Sebastien Bacher ha scritto:> Upstream comment
>
> 'smbc_new_context() calls smbc_setOptionUseCCache(context, True) if
> LIBSMBCLIENT_NO_CCACHE environemnt variable is not defined. I suppose it
> is not defined in your system, but can you please confirm it?is it correct to test if there is such a variable set in the user environment? This command
$ env | grep SMB; echo $?
1

answers your question?

> [...]
> I am not sure how exactly is ccache authentication handled, but first
> iteration uses smbc_setOptionFallbackAfterKerberos (smb_context,
> op_backend->user != NULL). I wonder if it helps to specify the username
> in the URI, e.g. gio mount smb://username@server/share?'
there is no difference with or without the username from the command gio mount... in both cases ask me a password and if I press return without typing a password or I press Ctrl-c the share is correctly mounted...

If you need some more infos or do you want to suggest me something else please let me know

Piviul

Revision history for this message
Sebastien Bacher (seb128) wrote :

Upstream posted a potential fix
https://gitlab.gnome.org/GNOME/gvfs/merge_requests/34

Would you be able to rebuild a pacakge with that change to test it? If not we can build/provide one for testing, let us know

Revision history for this message
Sebastien Bacher (seb128) wrote :

Debug version uploaded to https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa/+build/16391488 you need to download the debs corresponding to the ones you have installed (dpkg -l | grep gvfs) and install them with dpkg -i *.deb then restart your user session

Revision history for this message
piviul (piviul) wrote :

BINGO!

I have downloaded the packages you provided me in https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa/+build/16391488, installed them and now nautilus (gvfs) use, as expected, cached credential to access to samba shares and doesn't ask for a password.

Thank you very much Sebastien!

...but now do you think these patched gvs packages will be available to the official ubuntu 18.04 repositories?

Piviul

Revision history for this message
Sebastien Bacher (seb128) wrote :

The fix first needs to be landed upstream/in the current Ubuntu serie, then we can add it to the SRU backlog

Revision history for this message
Sebastien Bacher (seb128) wrote :

The patch has been fixed in upstream git now

Changed in gvfs (Ubuntu):
status: Triaged → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.