Bug 10321 - sysvolcheck uncaught exception
sysvolcheck uncaught exception
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Tools
4.1.3
x64 Linux
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks: 11924
  Show dependency treegraph
 
Reported: 2013-12-13 10:23 UTC by Marc Muehlfeld
Modified: 2017-02-17 14:35 UTC (History)
4 users (show)

See Also:


Attachments
SysVol share content that causes the exception (zipped incl. xattrs) (1.96 KB, application/x-bzip2)
2013-12-13 10:23 UTC, Marc Muehlfeld
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Muehlfeld 2013-12-13 10:23:37 UTC
Created attachment 9525 [details]
SysVol share content that causes the exception (zipped incl. xattrs)

# samba-tool ntacl sysvolcheck
ERROR(<type 'exceptions.TypeError'>): uncaught exception - (61, 'No data available')
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/netcmd/__init__.py", line 175, in _run
    return self.run(*args, **kwargs)
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/netcmd/ntacl.py", line 249, in run
    lp)
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/provision/__init__.py", line 1686, in checksysvolacl
    fsacl = getntacl(lp, dir_path, direct_db_access=direct_db_access, service=SYSVOL_SERVICE)
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/ntacls.py", line 73, in getntacl
    xattr.XATTR_NTACL_NAME)



If I run sysvolreset to fix the errors, then the check runs fine.


SysVol share is on XFS.
Comment 1 heupink 2014-08-18 08:15:42 UTC
Seeing a similar error, on sernet 4.1.7 and 4.1.9, on ext4:

root@dc3:~# samba-tool ntacl sysvolcheck
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[netlogon]"
Processing section "[sysvol]"
ERROR(<type 'exceptions.TypeError'>): uncaught exception - (61, 'No data available')
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 175, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 249, in run
    lp)
  File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1686, in checksysvolacl
    fsacl = getntacl(lp, dir_path, direct_db_access=direct_db_access, service=SYSVOL_SERVICE)
  File "/usr/lib/python2.7/dist-packages/samba/ntacls.py", line 73, in getntacl
    xattr.XATTR_NTACL_NAME)
root@dc3:~# 

Also here: samba-tool ntacl sysvolreset works, and after that also samba-tool ntacl sysvolcheck reports success.
Comment 2 Marc Muehlfeld 2016-08-26 01:08:25 UTC
Update: Samba 4.5.0rc2 still shows an exception when running the sysvolcheck:


[root@DC1 samba-4.5.0rc2]# samba-tool ntacl sysvolcheck
ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception - ProvisioningError: DB ACL on GPO directory /usr/local/samba/var/locks/sysvol/samdom.example.com/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9} O:LAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) does not match expected value O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) from GPO object
  File "/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/__init__.py", line 176, in _run
    return self.run(*args, **kwargs)
  File "/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/ntacl.py", line 270, in run
    lp)
  File "/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py", line 1723, in checksysvolacl
    direct_db_access)
  File "/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py", line 1674, in check_gpos_acl
    domainsid, direct_db_access)
  File "/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py", line 1621, in check_dir_acl
    raise ProvisioningError('%s ACL on GPO directory %s %s does not match expected value %s from GPO object' % (acl_type(direct_db_access), path, fsacl_sddl, acl))
Comment 3 SATOH Fumiyasu 2017-02-02 09:42:45 UTC
(In reply to Marc Muehlfeld from comment #2)

I'm seeing the same problem with Samba 4.5.3.

Marc, are you using `idmap_ldb:use rfc2307 = yes` in your smb.conf?
If so, disable it temporary, run `samba-tool ntacl sysvolreset`,
re-enable it, and try `samba-tool ntacl sysvolcheck` again.
I can solve the `sysvolcheck` error by this steps.

Is this a bug of `idmap_ldb:use rfc2307 = yes`?
Comment 4 tim.dittler 2017-02-15 09:20:08 UTC
(In reply to SATOH Fumiyasu from comment #3)

I also have the problem on 4.5.5-SerNet-Ubuntu-13.trusty

The procedure with idmap_ldb:use rfc2307 did not help. Neither does samba-tool ntacl sysvolreset
Comment 5 tim.dittler 2017-02-17 10:24:41 UTC
The part of the configuration that causes the error for me is

vfs objects = full_audit
full_audit:prefix = %u|%I|%S
full_audit:success = mkdir rename unlink rmdir pwrite
full_audit:failure = none
full_audit:facility = local7
full_audit:priority = NOTICE
Comment 6 Stefan Metzmacher 2017-02-17 13:55:34 UTC
(In reply to tim.dittler from comment #5)

We use the following logic for an addc:

  if (lp_server_role() == ROLE_ACTIVE_DIRECTORY_DC) {
      const char **vfs_objects = lp_vfs_objects(-1);
      if (!vfs_objects || !vfs_objects[0]) {
          if (lp_parm_const_string(-1, "xattr_tdb", "file", NULL)) {
              lp_do_parameter(-1, "vfs objects", "dfs_samba4 acl_xattr xattr_tdb");
          } else if (lp_parm_const_string(-1, "posix", "eadb", NULL)) {
              lp_do_parameter(-1, "vfs objects", "dfs_samba4 acl_xattr posix_eadb");
          } else {
              lp_do_parameter(-1, "vfs objects", "dfs_samba4 acl_xattr");
          }
      }

      ...
  }

That means if you explicitly set 'vfs objects' you need to add
the default ones explicitly too.

I guess

  vfs objects = full_audit dfs_samba4 acl_xattr

is what you need.
Comment 7 tim.dittler 2017-02-17 14:35:57 UTC
(In reply to Stefan Metzmacher from comment #6)

Thank you very much for pointing this out.