Bug 11790 - Unable to connect to share unless "Guest access" is checked
Summary: Unable to connect to share unless "Guest access" is checked
Status: RESOLVED INVALID
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.3.6
Hardware: x64 Linux
: P3 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-14 05:44 UTC by Chris Peñalver
Modified: 2016-06-04 16:59 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Peñalver 2016-03-14 05:44:37 UTC
Upstreaming from:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1556740

What is expected to happen:
On the Ubuntu 16.04 samba server with hostname HOSTNAME log in as first user created when installing USERNAME with password PASSWORD > create a new folder via nautilus (no gksudo) called test > secondary click test > Properties > tab Local Network Share > check "Share this folder" > Share name: test > other checkboxes unchecked > click button "Create Share"

On a Ubuntu 16.04 client click Places > Network > Windows Network > WORKGROUP > HOSTNAME > test > in the new connection window it notes at top:
Password required for share test on HOSTNAME

to the right of "Connect As" click radio button "Registered User" > put in Username field USERNAME > put in field Domain WORKGROUP > put in field Password PASSWORD > click radio button Forget password immediately > Connect

and it does so.

What happens instead is the connection window comes back up, but this time the "Connect As" radio button is now on Anonymous (Default) and everything else is grayed out. Hitting the X to close the window intermittently shows:

Unable to access location
Failed to mount Windows share: Invalid argument

The only way to allow the share to be connected is if one clicks on the server the checkbox "Guest access (for people without a user account)".

This prevents easily implementing secure and authenticated data transfers between server and client.

Attempting to connect via Windows 10 client notes Access Denied.

Attempting to smbclient via the Ubuntu 16.04 client notes:
smbclient -I IPADDRESS -W WORKGROUP -U USERNAME -D test -P PASSWORD -d 4
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
doing parameter workgroup = WORKGROUP
doing parameter server string = %h server (Samba, Ubuntu)
doing parameter dns proxy = no
doing parameter log file = /var/log/samba/log.%m
doing parameter max log size = 1000
doing parameter syslog = 0
WARNING: The "syslog" option is deprecated
doing parameter panic action = /usr/share/samba/panic-action %d
doing parameter server role = standalone server
doing parameter passdb backend = tdbsam
doing parameter obey pam restrictions = yes
doing parameter unix password sync = yes
doing parameter passwd program = /usr/bin/passwd %u
doing parameter passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
doing parameter pam password change = yes
doing parameter map to guest = bad user
doing parameter usershare allow guests = yes
pm_process() returned Yes
tdb(/var/lib/samba/private/secrets.tdb): tdb_open_ex: could not open file /var/lib/samba/private/secrets.tdb: Permission denied
Could not open tdb: Permission denied
Failed to open /var/lib/samba/private/secrets.tdb
ERROR: Unable to open secrets database

It is confirmed the file /var/lib/samba/private/secrets.tdb exists on both server and client, and the permissions for this file have not been adjusted in anyway. It's the default setup after installing the samba package.

Also, I'm not convinced (perhaps naively) it's a nautilus bug here. However, I reserve final judgment for samba developers on this.