Samba and system passwords should be synchronized.

[Eric S. Johansson]

Samba is set up to export home directories automatically on a per user basis.
and as one would expect, you need your username and password to access those
directories. Unfortunately, the only way to activate the username and password
is to login and 'sudo smbpasswd -a'. The same is true if you create a share
independent of the home directories.

the user should not have to do this. I know all of the reasons why it happens
but for the relatively naïve user or the one just trying to get a job done, they
should not have to do this. The user password should be shared with Samba or at
least change the samba setup so that home directories are not exported
automatically, that the user must export their own home directory explicitly and
in the process enter their password so that everything will work as expected.

the same thing should be true for shares shared between groups of users. It
should be possible to say "this share has these members in common". Yes, I'm
heading towards ubuntu as a general-purpose samba server. :-)

To reproduce:
1 ubuntu system
1 xp system

use existing or create user ubuntu account
from Windows XP machine, view workgroup computers.
select ubuntu machine.
at this point you should be given a prompt to enter username and password
enter the ubuntu username and corresponding password
it should be rejected

login to window on ubuntu machine and in terminal window type:
smbpasswd -a <ubuntu username>
enter password

try again to access the share with the username and password used above and it
should succeed.

as I said the user should not have to do this. synchronizing or entering
passwords should be a normal part of the share exportation process.

[Dennis Kaarsemaker (dennis)]

Maybe SMB can use PAM?

[z_diver (chuck-lagunadata)]

I agree. The Shared Folder dialog is pretty useless without the abilty to set your smbpasswd. Since it's already running with sudo permissions it seems it could be fixed quickly by adding a couple of password boxes and a button to run smbpasswd -a. Eventually there should be a checkbox to keep passwords synchronized with user accounts also.

[Laurent CHARTRAIN (darksilver)]

It is absolutely necessary to synchronize samba user and system user !
Because the "share folder" dialog can't work if the user don't do the "smbpasswd -a" in console !!!
It is totally NOT user friendly

If the sync is a problem, why not asking an user/pass for SMB when using the "share folder" dialog ???

How can something like that stay for a distribution like Ubuntu which is supposed to be a Desktop distro !!?

A normal user will use the share dialog, add a folder an test to access to it from another computer, of course it won't work because nothing tells him to do a smbpasswd -a.
Result: He will think only one thing : "ubuntu sucks", just because of a so little fix to do hasn't be done (asking a password or sync with system account when adding a folder)...

[Phil Bull (philbull)]

This is still an issue in Feisty. After setting up a new SMB share and setting the permissions of the shared directory to global read/write, other Ubuntu computers (those with the same username/password on them) are able to connect to the share without problems.

However, Windows XP clients on the network cannot access the share without a username and password being entered. Unless 'smbpasswd -a username' has been run, the username and password entered on the Windows computer will never be accepted, so the share is inaccessible. There should probably at least be a graphical interface for smbpasswd, as I imagine a lot of users come up against this issue.

[Huygens (huygens-25)]

A suggestion could also be that when a user set up a new share, it is asked to specify which account can access it, and if one or some of this accounts do not have a Samba encrypted password, a a graphical front-end to smbpasswd should come up and ask the user to specify for those account a password.
Of course, "sudo" authentication might apply in this case.

I think this bug should be moved from wishlist to Feisty+1 mandatory, because I am helping countless user with this issue on the Ubuntu forums! The main feedback from those who write one is that it is almost impossible for them to figure out such tricks, also using the command line to be able to share directories is probably not "for human beings" or let's say that it does not "just work" ;-)
My deep apologise to have re-use Ubuntu well known moto, but I hope to promote this bug to a higher priority :-)

[Rob Caskey (rcaskey)]

https://wiki.ubuntu.com/SimpleSambaIntegrationSpec should provide a solution to this problem, can someone please review it?

[tobyadams87 (tobyadams87)]

Definitely a mandatory addition to a near future release of ubuntu!!!

[Huygens (huygens-25)]

About the SimpleSamba spec. The major technical problem would be that it is not possible (to the extend of my knowledge) to synchronise already set user passwords with Samba once it is installed. The reason is that the passwords are kept in a hash form, thus they cannot be decrypted to be sync with Samba. Thus, after installing Samba, each user would have to enter its password to enable its user account.
So the implementation of the spec might be pretty difficult, unless Samba could use the same authentication back-end as the system login...

[Jerome Haltom (wasabi)]

Samba cannot use the same back-end.

But this isn't that big of a deal, the user would just need to change
his password once before he would be allowed to use those services. UI
would have to be made to instruct the user to do so, perhaps before
enabling any file shares.

On Tue, 2007-04-10 at 13:50 +0000, Huygens wrote:
> About the SimpleSamba spec. The major technical problem would be that it is not possible (to the extend of my knowledge) to synchronise already set user passwords with Samba once it is installed. The reason is that the passwords are kept in a hash form, thus they cannot be decrypted to be sync with Samba. Thus, after installing Samba, each user would have to enter its password to enable its user account.
> So the implementation of the spec might be pretty difficult, unless Samba could use the same authentication back-end as the system login...
>

[Rob Caskey (rcaskey)]

And more importantly, this spec would hash the passwords by pam as users were created initially so that every _new_ install would have working samba users, as well as upgraded users who had changed their passwords. I'll clarify this on the spec.

So, if you buy a new machine, do a fresh install of Feisty, and then install samba, you will be able to log in immediately to samba because your password was hashed in the format samba needs when you first set your password, even though samba wasn't installed. The hash is there waiting for samba when/if samba is installed.

[Eric S. Johansson (esjh)]

I've been thinking about this problem a bit more since I filed the initial bugs and I think password synchronization is only part of the problem.

The initial thought was for a naïve user. A naïve user wants to export a share so he/she can use it from another machine. They might even give their password to other people so they can access the share. A more advanced user would want more control over who gets their password and what people can access the share.

I believe the advanced user configuration is something that can be implemented relatively easily. It would require modifying the share folder dialog box to have three additional fields. Two of the field would be password and password confirmation and the third would be a list of users permitted.

In the future, synchronization could be enabled with the addition of a checkbox indicating the users desire to use their system password.

 the primary advantage to this potentially simple technique is that it gives the user a hint that something else needs to be done as well as making it possible for them to do it in one place in the GUI.

[Eric S. Johansson (esjh)]

in bug 103708 Jonathan Watmough posted a small image showing where one could put a user's button to activate what users are associated with what shares. what Jonathan is concerned with is an important problem, it's just not this problem. I propose adding two more fields to the basic dialog box (see attached) so that one can specify the user and password combination one would use to access that share. if you want multiple users and passwords for a share, one could extend this dialogue to have a tabular box for user name and password type information.

I apologize for the crudeness of the image but I have an upper extremity disability plus significant tremors which makes it hard to control mouse etc. and then I further handicapped myself by doing this in Windows paint.

[Huygens (huygens-25)]

Thank you Eric for your work :-) that is a nice initiative.

However, there is a caveat with your approach and the one taken in Bug 103708. The problem is that it tends to associate a share with a credential. Nevertheless, credentials in Samba are "samba-wide", meaning there can only be one login/password combination for all the shares in Samba. So if the user set a specific login for share A and define the password. When later he wants to create a new share (let's call it B), and he wants to access it using the same specific login, there is no need for him to use the same password.
If we had the user credentials definition in the GUI that share a folder, we will make the end-user think that a credential is bound to a share, which is not the case in Samba configuration (apart a few exceptions like home directories).

So a more logical place would be a central Samba configuration GUI like the one which can be found in System->Administration->Shared folders. Where you can click to set Samba-wide settings such as the domain/workgroup for the computer, etc. However, in the end-user logic, this is not the expected place, and if we put it here, I'm sure we will find countless forum posts about where to set Samba password.

A work-around solution would be to present to a user when he first shares a folder a specific GUI where he can set Samba-wide parameters (such as the domain/workgroup and his credentials). There is however another caveat, which is when there are multiple user at home. If user A install Ubuntu and share folder /tmp. User B, who is using another machine on the network and who knows about the share, wants to access it. User B enters his login name and password and the access is refused. User A would then need to understand that he should create a local user named B and then create the Samba credentials. Unless he is an IT guy, this might not be obvious to him.

Another idea could be have a simplified sharing mechanism for home users. Where a guest account is activate by default so when a share is opened, people on their network can view them (but not modified them). Then we could imagine that the smbpasswd would be automatically created when a user is created (meaning also in the Ubuntu installation process). If a user set his login credentials, he could then access read/write the shares.
There are some caveats to that, mainly for SOHO, Enterprises and enthusiasts where they do not want to have a smb account for each user they are creating. They probably do not want the guest account thing, etc.

So, I do not have solution to this problem. The approach of Windows (at least until XP, I have not seen Vista yet) is equally not satisfying, so we cannot get inspiration from there. As for how the case is handle on a Mac, I have no clue! What about the other Linux distro or the BSD*? Does anyone knows how it is done on them?

[Eric S. Johansson (esjh)]

Huygens wrote:
> Thank you Eric for your work :-) that is a nice initiative.

Glad to be of help. I'm also making trouble in the anti-spam (reputation-based)
arena and small-scale Web frameworks (learn hours, not days or weeks), and
speech recognition-based accessibility.
>
> However, there is a caveat with your approach and the one taken in Bug
> 103708. The problem is that it tends to associate a share with a credential.
> Nevertheless, credentials in Samba are "samba-wide", meaning there can only
> be one login/password combination for all the shares in Samba. So if the user
> set a specific login for share A and define the password. When later he wants
> to create a new share (let's call it B), and he wants to access it using the
> same specific login, there is no need for him to use the same password. If we
> had the user credentials definition in the GUI that share a folder, we will
> make the end-user think that a credential is bound to a share, which is not
> the case in Samba configuration (apart a few exceptions like home
> directories).

Are you referring to the Ubuntu's Samba implementation or Samba in general? I
have set up Samba with different credentials for different shares and not just
with the home directory. This is why I thought about binding credentials to a
share. If you want to have multiple credentials associated with a share, Samba
has a way of creating groups.

As for associating a set of credentials with a share, I don't think that's bad.
  We need some mechanism that the user will be driven to to enter credentials
for sharing. If we don't do that, people will not set their share username and
password. Maybe, the user model would be forcing the user to enter a username
and password if there is none and giving them the option to set different
usernames and passwords if one exists.

The workflow would be something like:

Create the first share with Mandatory username password before accepting share
definition

Create second share

optional username password but user is notified of that option and given the
ability to set username and password on the share dialog box (don't make me
click another button please, my hands hurt)

>
> So a more logical place would be a central Samba configuration GUI like the
> one which can be found in System->Administration->Shared folders. Where you
> can click to set Samba-wide settings such as the domain/workgroup for the
> computer, etc. However, in the end-user logic, this is not the expected
> place, and if we put it here, I'm sure we will find countless forum posts
> about where to set Samba password.

Which is why it belongs on the user form to create a share. It's horrible but
one must always accept that the user hate surprises it wants to be led by the
nose. To those of us who grew up using command lines, it's anathema. To people
like my wife it's comfort.

> A work-around solution would be to present to a user when he first shares a
> folder a specific GUI where he can set Samba-wide parameters (such as the
> domain/workgroup and his credentials). There is however another caveat, which
> is when there are multiple user at home. If user A install Ubunt...

[Max (mblaze)]

The cleanest way to do this is to not use /etc/passwd or the smb database and switch the entire user/password infrastructure to LDAP. This would of course be quite a large undertaking as it would affect much more than just SAMBA, but it might be well worth it for future growth, especially when it comes to enterprise use.

[Steve Langasek (vorlon)]

I believe you will find that this bug is now resolved in hardy. :) If you install the samba server task, or if you use nautilus-share to manage shares, the libpam-smbpass package will automatically be pulled in, causing passwords to be synchronized between the system and Samba password stores from that point on.

This is not installed by default because NTLM password hashes are weaker than standard md5 passwords on disk, and because the Ubuntu policy is to not listen on any ports by default; but if you choose to configure filesharing, it should now be pretty seamless going forward.

[Jackflap (deriziotis)]

I just tested this in Karmic and this is broken again.

I could not access a share I created through nautilus until I ran sudo smpasswd and added my user to the smb user db.

[Jackflap (deriziotis)]

This only occurs if you have samba installed prior to nautilus installing it for you. See https://bugs.launchpad.net/ubuntu/+source/samba/+bug/460256

[aa (aurelio-networkspace)]

I completely agree. I have occasionally had this problem with Ubuntu samba and gave up on it, not knowing what combination finally got it working when it did. I almost gave up on it after the last new install. I never considered installing Nautilus in a certain order. I just did the default install and installed what I needed and sometimes it worked.

This got me going easy and simple. Thank you!