Troubleshooting SYSVOLSYNC in DSfW

By grohin


The sysvolsync utility is introduced to provide synchronization of sysvol and the underlying policies (Group policy objects) between the domain controllers of a domain. This utility when invoked on the PDC finds the domain controllers for the DSfW domain and initiates the synchronization process with them, contacting one domain controller at a time. During synchronization only the changes are transferred and not the entire data. This helps in faster synchronization between the domain controllers. All the POSIX file permissions and ACLs are retained during transfer. During the synchronization, changes are transferred from the first domain controller (holding the PDC Emulator role) to the other domain controllers. By default the sysvolsync cronjob is run every 30 minutes. For intermediate synchronization, you can invoke the utility using the following command:


The details of synchronization events are captured in the /var/opt/novell/xad/log/ sysvolsync.log file.

The log is something like:

[INFO:]sysvolsync started Wed Sep 12 11:30:01 2012

[INFO:]Temprorary Sock file : /var/opt/novell/xad/sysvol_sock.180428938321018
[INFO:]Syncing the changes to DomainController
[INFO:]Ticket cache is destroyed
[INFO:]sysvolsync stopped Wed Sep 12 11:30:01 2012

[INFO:]sysvolsync status: Successful


For unsuccesful sync, the log is something like:

[INFO:]sysvolsync started Tue Sep 11 17:56:29 2012

[INFO:]Temprorary Sock file : /var/opt/novell/xad/sysvol_sock.180428938332255
[ERR :]Unable to sync the changes to DomainController err 255
[INFO:]Ticket cache is destroyed
[INFO:]sysvolsync stopped Tue Sep 11 17:56:29 2012

[ERR :]sysvolsync status: Not Successful



As seen in the log, the error value is 255 for almost all unsuccessful cases. This value is not sufficient for debugging the root cause of problem, since it is the return value of command forked by sysvolsync command.

The following troubleshooting steps can be performed for solving the sysvolsync problem:

  1. /etc/ssh/ssh_config file should have GSSAPI related settings enabled.That is "GSSAPIAuthentication yes" should be there in the file, and should be uncommented and set to yes.

  • The forward and reverse lookup for all the DSfW domain controllers should be working.That is, the following commands should be working correctly.

    1. dig -t SRV _ldap._tcp.dc._msdcs.<domain-name> short

  • All the servers obtained should have forward and reverse lookup working.

If any of the DNS records are found missing, the missing records can be added using the DNS-DHCP Java Console tool.

OES 11 SP1: Novell DNS/DHCP Services for Linux Administration Guide

(If for some reason the records db is not updated by the Console, delete the zone records in /etc/opt/novell/named and restart novell dns using the command "rcnovell-named restart")
  • The /etc/hosts file of any on the DSfW controllers should not have any hostname to IP mappings for the servers, since DSfW controllers use DNS for domain resolutions. However, if for some reason its inevitable to have /etc/hosts mappings, please ensure that the mappings of hostnames for DSfW domain controllers is correct.


It's possible that the root cause of problem might be something other than what's listed in the article. The next level of debugging can be done using the steps enumerated here:


How To-Best Practice
Comment List
Parents Comment Children
No Data