Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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
    security = ADS
    password server = 192.168.1.2
    #root directory = /home/share/sharing
    log level = 2
    log file = /var/log/samba/%m.log
    smb ports = 139
    strict locking = no
    load printers = 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"
    admin users = @"DOMAINNAME+Domain Admins"
    guest ok = no
    read only = No
    create mask = 0765
    force directory mode = 0777
share|improve this question
    
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

2 Answers 2

up vote 2 down vote accepted
+25

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

http://support.microsoft.com/kb/2473205

share|improve this answer
    
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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.