Which Domain Group has write access to the samba netlogon share?

Hello UCS-Team and fellow Users,

I need to have write access for a domain admin to the netlogon share. Users administrator and a created domain/enterprise admin are denied access.

Which groups have write access to the sysvol shares?

In UCS4.1 the (synchronised) share was /var/lib/samba/sysvol//scripts, but has at some point changed to /var/lib/samba/netlogon. Testparm show the share points to /var/lib/samba/netlogon but I like to have a definitve statement by users in the know or the developers ;).

Thank you and kind regards,


P.S. were would failed logon attemps be logged in a readable manner? I set a higher samba debug level, but /var/log/samba/log,smbd was not very informative in this case.


You can figure that out easily via a call to getfacl /var/lib/samba/sysvol. By default the groups system and administrators have write access. The former is for machines, the latter for user accounts. You can modify the permissions with setfacl.

I’m somewhat confused by what you’ve written. In my installations the netlogon share is serving /var/lib/samba/sysvol/<my-domain>/scripts and not /var/lib/samba/netlogon or /var/lib/samba/netlogon/scripts (testparm proves that). Can you please post the output of grep -E -r 'netlogon|scripts' /etc/samba?

The permissions on /var/lib/samba/sysvol/<my-domain>/scripts match the ones I’ve mentioned above for sysvol.

With debug level set to at least 2 you’ll find messages about failed login attempts in /var/log/samba/log.smbd. Here are three examples:

[2017/09/13 13:06:59.671137,  2, pid=4568] ../source4/auth/ntlm/auth.c:430(auth_check_password_recv)
  auth_check_password_recv: sam_ignoredomain authentication for user [MBU-TEST\root] FAILED with error NT_STATUS_NO_SUCH_USER
[2017/09/13 13:08:08.262386,  2, pid=4702] ../source4/auth/ntlm/auth.c:430(auth_check_password_recv)
  auth_check_password_recv: sam_ignoredomain authentication for user [MBU-TEST\mbunkus] FAILED with error NT_STATUS_WRONG_PASSWORD
[2017/09/13 13:16:36.904394,  2, pid=6265] ../source4/auth/ntlm/auth.c:430(auth_check_password_recv)
  auth_check_password_recv: sam_ignoredomain authentication for user [MBU-TEST\yokel] FAILED with error NT_STATUS_ACCOUNT_DISABLED
  1. In the first example a login is attempted with a user that doesn’t exist in Samba (root only exists as Linux user but not as an LDAP/Samba account).
  2. In the second example the account exists, but the password is wrong.
  3. In the third example the account exists, the password is correct, but the account is locked.

Kind regards,

Hi Mosu,

thank You for Your very helpfull post.

Your answer considering the permissions of sysvol is spot on and I will check with facl-tools the permissions. My goal is to delegate permissions to a support user group and had not luck adding users to the existing groups on our UCS pdc.

In regards to the different sysvol-shares/-path:

We have a ucs@school setup with domain controllers at each site. With ucs@school 4.1 the netlogon folder was synced across the whole domain, e.g. logon scripts for one site were synced to every other pdc. This behaviour was changed with one minor upgrade to the 4.1 system, sysvol (w. path /var/lib/samba/sysvol//policies) gets still synced, but netlogon (and this now w. path /var/lib/samba/netlogon) does not.

Also: On our test systems (UCS 4.1-4) domain master and site pdc show with testparm

        comment = Domain logon service
        path = /var/lib/samba/netlogon
        case sensitive = No
        read only = No

        path = /var/lib/samba/sysvol
        case sensitive = No
        acl xattr update mtime = Yes
        read only = No

Output of grep -E -r ‘netlogon|scripts’ /etc/samba

/etc/samba/base.conf:   path = /var/lib/samba/netlogon
/etc/samba/smb.conf.debian:# in the [netlogon] share
/etc/samba/smb.conf.debian:# Un-comment the following and create the netlogon directory for Domain Logons
/etc/samba/smb.conf.debian:;   path = /home/samba/netlogon

So where does the sysvol/ part come from?
I am just a simple samba3 guy, so maybe I am looking in the wrong places.

Regarding logs:
Thank You for Your help again. I hoped there would be some nice, clean logfiles considering failed logins with such a polished system as UCS :).

Thanks again for Your excellent post.


Ah, you’re using UCS@school. That wasn’t obvious from your original post. The configuration snippets I’ve posted come from a standard (non-school) UCS system, and those are definitely configured differently than school systems. Therefore the discrepancies are to be expected.