CentOS - Aug 2016 - "Windows" share issue; access via smb:// fails, "mount -t cifs" works

Hi,

Is anyone here using smb:// URLs to access "Windows" shares? I've
been
doing this for a while with common file systems at work, and it used to 
work just fine. Then I while back, I started getting issues; I will now 
just keep getting asked for a password when I try to access something 
through smb://. I thought at first that this meant there had been some 
kind of change related to permissions on the shares, but now I find that 
I can mount them just fine using "mount -t cifs".

In other words, I get:

gvfs-mount smb://mydomain\;toralf.lund at theserver/myshare
Password required for share myshare on theserver
Password:
Password required for share myshare on theserver
Password:
Password required for share myshare on theserver
Password:

[ I enter the correct password, but gvs-mount keeps asking... Behaviour 
is the same if I try to open the URL in the file manager instead. ]

mount -t cifs -o user=toralf.lund,workgroup=mydomain //theserver/myshare 
/tmp_mnt/
Password:

[ At this stage the filesystem is mounted, as long as I enter the 
correct password. ]

Does anyone have any idea what is going on here? Why does the VFS mount 
fail when mount.cifs works on the same share? Is there a difference in 
the way authentication works, or something? Has there been a change to 
the smb support that might explain this?

This is on a CentOS 6 x86_64 installation with all updates applied.

- Toralf

On 30/08/16 10:00, Toralf Lund wrote:
> Hi,
>
> Is anyone here using smb:// URLs to access "Windows" shares?
I've been
> doing this for a while with common file systems at work, and it used 
> to work just fine. Then I while back, I started getting issues; I will 
> now just keep getting asked for a password when I try to access 
> something through smb://. I thought at first that this meant there had 
> been some kind of change related to permissions on the shares, but now 
> I find that I can mount them just fine using "mount -t cifs".
I found out a bit more about this - I believe that I have the issue 
described here:

http://community.netapp.com/t5/Network-Storage-Protocols-Discussions/samba-3-6-23-30-on-CentOS-gt-error-in-smbclient/td-p/118268

In other words, the problem is that "SPNEGO" fails. If I add
"client use
spnego = no" to /etc/samba/smb.conf, smbclient access works (I found 
that I also got a problem there), but unfortunately, gvfs-mount still 
doesn't. The debug output that I get if I run gvfsd on the command line 
with "GVFS_DEBUG=1" and "GVFS_SMB_DEBUG=99" actually still
report SPNEGO
errors, so it would appear that the smp.conf option is for some reason 
ignored. In other words the question may be:

How do I disabled SPNEGO for gvfs-mount?

Also, the above suggest that whether this problem occurs depends on 
whether "you have SMB signing turned on or not under the 'cifs'
options
section", but it not clear to me what options exactly this refers to. 
Anyone?

Oh, and some other posts I found seem to indicate that mount.cifs 
doesn't support SPNEGO yet, so I guess that's why a "normal"
mount works.

- Toralf

>
> In other words, I get:
>
> gvfs-mount smb://mydomain\;toralf.lund at theserver/myshare
> Password required for share myshare on theserver
> Password:
> Password required for share myshare on theserver
> Password:
> Password required for share myshare on theserver
> Password:
>
> [ I enter the correct password, but gvs-mount keeps asking... 
> Behaviour is the same if I try to open the URL in the file manager 
> instead. ]
>
> mount -t cifs -o user=toralf.lund,workgroup=mydomain 
> //theserver/myshare /tmp_mnt/
> Password:
>
> [ At this stage the filesystem is mounted, as long as I enter the 
> correct password. ]
>
> Does anyone have any idea what is going on here? Why does the VFS 
> mount fail when mount.cifs works on the same share? Is there a 
> difference in the way authentication works, or something? Has there 
> been a change to the smb support that might explain this?
>
> This is on a CentOS 6 x86_64 installation with all updates applied.
>
> - Toralf
>