# ldap samba user access issue

I have a samba share that is on the LAN. It is auth'd via ldap. Users access file system via ad windows shares. There are shortcuts in directories that point to dir's on samba.

Typically a user will click the shortcut to the smb dir, and will be met with a permission denied error. Upon closing explorer and reopening, it will work.

DNS is handled by the domain controller, and that is the only server any of the machines use for DNS.

Nothing in eventvwr.

Only see successful auth entries in samba log.

Any ideas?

smb.conf

[global]
workgroup = DOMAINNAME
realm = DOMAINNAME.LOCAL
server string = DOMAINNAME-SAMBASHARE
interfaces = eth1
#root directory = /home/share/sharing
log level = 2
log file = /var/log/samba/%m.log
smb ports = 139
strict locking = no
local master = No
domain master = No
wins server = 192.168.1.2
wins support = Yes
idmap uid = 500-10000000
idmap gid = 500-10000000
winbind separator = +
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
#valid users = "@Domain Users"

[SMB-DocServ]
comment = SMB Document Share
path = /home/share/sharing/
valid users = @"DOMAINNAME+Domain Users"
guest ok = no
force directory mode = 0777

• Can you provide us with the details of the Samba configuration? Did you try to raise the Samba log level? – Valentin Jun 17 '12 at 14:37
• Updated OP. Nothing notable in the logs; only see successful opens (e.g. NT_STATUS_OK) – stormdrain Jun 18 '12 at 13:34
• Is the samba server joined into a domain? – Valentin Jun 23 '12 at 18:53
• Yes it is on the domain. – stormdrain Jun 24 '12 at 18:31

I would perform a packet capture to confirm it is connecting to the desired computer where the share is located when the error occurs.

Does the behavior change if using an ip address instead of the computer short name? I.e., does it always work if using the ip address? Or if using an fqdn instead of the short name?

You may want to try this from a client that has the most recent version of the client MRXSMB components. If it always works on a patched client, it may be a bug in Windows. Those are published here:

List of currently available hotfixes for the File Services technologies in Windows Server 2008 and in Windows Server 2008 R2

• Perform the capture on the client that is trying to connect? Also, unfortunately (or fortunately), none of those hotfixes are applicable. The closest looking one was the race condition one, but the hotfix scenario doesn't match what it happening here. – stormdrain Jun 18 '12 at 14:02
• Yes, perform the capture on the client. For the hotfixes, the suggestion was to reproduce the symptom on a client that has the latest patches, not to find one that matches the symptom. – Greg Askew Jun 18 '12 at 14:03
• OK, will try the cap on a client. I don't understand the last part of your comment...Could you clarify? Thanks. – stormdrain Jun 18 '12 at 14:17
• Apply the recommended patches to a client, and attempt to reproduce the symptom. – Greg Askew Jun 18 '12 at 14:21
• But the symptoms on those patches don't match my error. What should I be looking for in the capture? – stormdrain Jun 20 '12 at 2:36

As you have mentioned in the comments section, your Samba server is joined against a domain. I have seen various timing problems with joined Samba servers. Usually it helps to:

• Rejoin the Samba server against the domain
• Restart the Samba server

If possible I recommend to do both steps nightly with the help of a cronjob.

If that doesn't help I can only advice to install tshark and listen on the network interface. Tshark tries to translate the detected protocols, so you should see very soon what the source of problem could be.