When you say "remotely" you mean from another computer. Or do you mean
from another subnet?
If you recreated both samba accounts, and the two accounts behave
differently, then the problem may be in the underlying unix account.
Are the unix accounts defined in /etc/passwd?
I also find it interesting that the two users do NOT have user SID's
that are sequential (or at least in a closer range.) Are you using
idmap to allocate
Can you run
# wbinfo -n user1
# wbinfo -n user2
This will show the user sids of the users
# wbinfo -s sid_of_user_one
# wbinfo -s sid_of_user_two
The name-to-sid and sid-to-name assignment should match up.
Also try the following
#id user1
# id "YOURDOMAIN\user1" (if you are using winbind)
#id user2
# id "YOURDOMAIN\user2"
On 06/26/12 08:25, Claesen Dirk wrote:
> Dear,
>
> I have a working Samba 3.5.6 running on one of my servers onto which
> (existing) users can successfully log on.
> Recently, I needed to add some projects and some users but I cannot succeed
> in letting these new users access the shares.
>
> The smb.conf file is very small and I had only 4 users until now.
> In the following smb.conf, projA_dirs is only accessed by user1, while
> projB_dirs is the new project I need to add and this one will be accessed by
> user2
> user1 is accessing projA_dirs since years without any problem, user2 is the
> one I fail to add.
>
> Contents of smb.conf:
>
> [global]
> workgroup = TECH_GRP
> server string = Samba %v on (%h)
> log level = 3
> log file = /usr/local/samba/var/log.%m
> max log size = 50
> dns proxy = No
> ldap ssl = no
> hosts allow = 192.168.5., 192.168.4., 192.168.3., 192.168.100.
>
> [all_dirs]
> comment = All directories on Server1
> path = /
> read only = No
>
> [projA_dirs]
> comment = All ProjectA directories on Server1
> path = /disk/projA/prod
> read only = No
>
> [projB_dirs]
> comment = All ProjectB directories on Server1
> path = /disk/projB/prod
> read only = No
>
>
> The initial samba setup was a migration from a Samba 2 server which used the
> smbpasswd file. In order to convert this into a tdbsam, I used the command
> "pdbedit -i smbpasswd -e tdbsam" at the time I set up the server. As written
> earlier in this mail, this never caused any problems.
>
> Now that I need user2 to access projB_dirs, I did the following:
> - Add projB_dirs to the smb.conf file
> - Ran "pdbedit -a user2" and provided the password
>
> After having added the share and the user I could access the new share with
> the new user when working directly on the Samba server (server1). However,
> when I try to connect from another Samba 3.5.6 server or from a Windows XP PC
> I get respectively a "session setup failed: NT_STATUS_LOGON_FAILURE" or
> "System error 1326 has occurred. Logon failure: unknown user name or bad
> password." error message. (there is no firewall blocking any ports between
> the servers or between the PC and server1)
>
>
> The output of pdbedit does not show any major differences for the two users
> to me:
>
> # ../bin/pdbedit -v -u user1
> Unix username: user1
> NT username:
> Account Flags: [UX ]
> User SID: S-1-5-21-1956562905-4024769754-4182693708-1500
> Primary Group SID: S-1-5-21-1956562905-4024769754-4182693708-513
> Full Name: user1 server1
> Home Directory: \\server1\user1
> HomeDir Drive:
> Logon Script:
> Profile Path: \\server1\user1\profile
> Domain: SERVER1
> Account desc:
> Workstations:
> Munged dial:
> Logon time: 0
> Logoff time: never
> Kickoff time: never
> Password last set: Tue, 26 Jun 2012 13:38:36 CEST
> Password can change: Tue, 26 Jun 2012 13:38:36 CEST
> Password must change: never
> Last bad password : 0
> Bad password count : 0
> Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
>
> # ../bin/pdbedit -v -u user2
> Unix username: user2
> NT username:
> Account Flags: [UX ]
> User SID: S-1-5-21-1956562905-4024769754-4182693708-1004
> Primary Group SID: S-1-5-21-1956562905-4024769754-4182693708-513
> Full Name: user2 server1
> Home Directory: \\server1\user2
> HomeDir Drive:
> Logon Script:
> Profile Path: \\server1\user2\profile
> Domain: SERVER1
> Account desc:
> Workstations:
> Munged dial:
> Logon time: 0
> Logoff time: never
> Kickoff time: never
> Password last set: Tue, 19 Jun 2012 17:20:33 CEST
> Password can change: Tue, 19 Jun 2012 17:20:33 CEST
> Password must change: never
> Last bad password : 0
> Bad password count : 0
> Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.
>
>
> Logging in with debug level 10 using smbclient from the other server gives me:
>
> ...
> got smb length of 35
> size=35
> smb_com=0x73
> smb_rcls=109
> smb_reh=0
> smb_err=49152
> smb_flg=136
> smb_flg2=51203
> smb_tid=0
> smb_pid=12023
> smb_uid=100
> smb_mid=3
> smt_wct=0
> smb_bcc=0
>
>
> Because I only had issues with the new users I added, I checked what would
> happen if I would remove user1 using pdbedit -x and then recreate that user
> using pdbedit -a. From that moment on I was also no longer able to log on
> with user1 remotely.
> As I thought there might be a problem inside the database I shut down smbd
> and nmbd, removed passdb.tdb and secrets.tdb, and restarted the daemons. This
> resulted in the two tdb files to be recreated after which I added user1 and
> user2 again using pdbedit -a. Again, I could only access the shares using
> either of these users directly from server1 but not from any of the other
> servers.
>
> Then I shut down the daemons again, restored the initial tdb files and
> restarted the daemons. With the initial tdb files back in place, I can login
> again remotely using user1 but not with user2 (even after I added the account
> again). Repeating my test connecting locally to the share, I noticed I am not
> able to connect locally with user1 to projA_dirs while it is possible to do
> it from the other server. I can connect locally using user2.
> I didn't test the local connectivity with user1 before I started playing
> around with the tdb files so I cannot confirm whether or not this was
> possible before.
>
> I'm looking for any hints that might help me understanding this issue and
> getting it solved. Local connectivity to the shares is not required but I
> must be able to connect using the new users from the Windows XP PC.
>
>
> Kind regards,
>
> Dirk Claesen
>
>
>
>
> This e-mail and any attachments may contain confidential and
> privileged information. If you are not the intended recipient,
> please notify the sender immediately by return e-mail, delete this
> e-mail and destroy any copies. Any dissemination or use of this
> information by a person other than the intended recipient is
> unauthorized and may be illegal.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
