Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a samba server that authenticates users using LDAP, however it does have kerberos enabled as well. Unfortunately users authenticated using kerberos cannot delete files. I can test this using smbclient - if I use the '-k' switch, I cannot delete the files, if I don't, I can. The users does have read/write/execute access to the directory from where he is trying to delete the file.

Any idea what might be wrong?

The smb.conf:

    security = user
    passdb backend = ldapsam:ldap://ldap1.[...]
    ldap ssl = start tls
    ldap suffix = dc=mff,dc=cuni,dc=cz
    ldap user suffix = ou=accounts
    ldap group suffix = ou=groups
    ldap admin dn = uid=[...]
    ldapsam:trusted = yes
    kerberos method = system keytab
    realm = [...]
    use spnego = yes
    unix extensions = no
    winbind enum users = Yes
    winbind enum groups = Yes
    winbind cache time = 7200

    idmap cache time = 7200
    idmap uid = 8000-50000
    idmap gid = 8000-50000
    name cache timeout = 7200

    delete readonly = yes

    comment = "Uzivatelska data"
    path = /export/home
    public = no
    writable = yes
    hide unreadable = yes
share|improve this question
First, you should post copies of your Samba configuration (smb.conf) file. Second, you should check Samba's log files (usually located under /var/log/samba, though different packages vary). You may need to increase the log verbosity, see for exact instructions. – Ryan B. Lynch Mar 22 '10 at 14:19
That's what I will hopefully do this evening, it's a production machine. – ondra Mar 22 '10 at 14:46
I did. I did a lot of debugging. In the end it seems that when I connect using Kerberos, the "SID" of the user is not read from LDAP, but is derived from "rid", which is algorithmically derived from UID (something like UID*2 + 1000). The problem is that during ACL comparison the SID of the file is actually somehow read from the LDAP database and it doesn't match with the "algorithmic" SID, the owner of the file is not owner and as such the delete operation fails.... Seems to be a bug in samba.... – ondra Apr 21 '10 at 22:26
up vote 0 down vote accepted

And finally, I probably found the answer: It seems that Samba 3.5 should solve it.

share|improve this answer

Your Answer


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.