10

Question for which I'm having trouble finding an answer on Google or Technet...

Does granting the SYSTEM user permissions to DFS-shared files and folders have any effect on DFS replication? (And while we're at it, is there any good reason not to let SYSTEM have permissions to DFS-shared files?)

It comes up because I have a collection of DFS namespaces and folders that I'm not able to make someone else's problem, and while troubleshooting a problem where one DFS replica just wasn't replicating with another for no discernible reason, I observed that the SYSTEM account didn't have any permissions granted to any of the files or folders in the folder in question.

So I set SYSTEM to have full control and propagated it down, and our DFS health diagnostic reports went from showing a backlog of ~80 files to a backlog of ~100,000... and things started replicating, including a number of files that had been missing on one server or the other (so more than just the permissions changes started replicating).

Naturally, this made me curious as to whether or not DFS needs the SYSTEM account to have permissions to do its work, or if perhaps it was just any change to folder tree in question that prompted DFS to jump into action. If it matters, our DFS namespaces were set up under 2000/2003, and I have just recently finished upgrading all the servers to 2008 R2 or 2012 (with UAC enabled, blech), but have not yet gotten around to raising the DFS namespace functional levels to Server 2008.

(And bonus points if anyone has an official Microsoft article on NTFS file permissions and the SYSTEM account as it pertains to DFS or network files.)

Improve this question
3
  • When you upgraded the servers, did you follow the FRS-to DFS migration guide? microsoft.com/en-us/download/confirmation.aspx?id=580
    – Rex
    Aug 2, 2013 at 2:22
  • @Rex I didn't do the FRS -> DFS migration, and I'd hazard a guess to say that any guides, best practices common sense or rational thought was probably not followed, but we've been using DFS (as opposed to FRS) for quite some time. I have little doubt that the reason it works so poorly is because of the way it was initially set up, as well as the way it was migrated. The upgrade in question was a namespace version upgrade, not an FRS -> DFS upgrade. I'll correct that omitted word now.
    – HopelessN00b
    Aug 2, 2013 at 14:07
  • if you were doing any kind of replication in DFS under 2000/2003, it would have been using would have to have been using FRS to do the replication. DFS-R for DFS replication wasn't available until 2003 R2. DFS on 2008 R2 no longer supports FRS for replication and 2008 R2 servers could not replicate with older 2003 based DFS namespaces unless you upgraded all the servers to 2003 R2 (or later) and migrated to DFS-R for replication.
    – Rex
    Aug 2, 2013 at 14:58

2 Answers 2

Reset to default
9
+100

This thread on technet says SYSTEM needs full control. Not a very official source however, and further testing proves that it is wrong.

DFS Replication Service

I took a look at the DFS services on my Server 2008R2 machine with Process Explorer. dfsrs.exe, the Distributed File System Replication service, runs as "NT Authority\SYSTEM". However, it has SeBackupPrivilege and SeRestorePrivilege:

Screenshot of dfsrs.exe permissions

From Microsoft Privilege Constants:

SeBackupPrivilege - Required to perform backup operations. This privilege causes the system to grant all read access control to any file, regardless of the access control list (ACL) specified for the file. Any access request other than read is still evaluated with the ACL.3

SeRestorePrivilege - Required to perform restore operations. This privilege causes the system to grant all write access control to any file, regardless of the ACL specified for the file. Any access request other than write is still evaluated with the ACL. Additionally, this privilege enables you to set any valid user or group SID as the owner of a file.

With those permissions, the DFS Replication Service can ignore any file permissions - it is given permission to read, write, and set permissions on any file it pleases.

Testing

I created a folder in one of my DFS shares with a few files in it, set my account as the owner, and removed all permissions except for my account.

DFS replicated it to all the other servers without issue, and all the replicas had the same permissions.

Thus DFS is not dependant on any file system permissions to replicate.

I suspect in your case simply making any changes to the files would have caused DFS to wake up and see that they needed replicating. No idea what would have caused that situation in the first place though.

Improve this answer
2
  • 1
    Outstanding answer. I'll give your check mark and bounty in 5 days, on the off chance that someone can come along and top this.
    – HopelessN00b
    Aug 2, 2013 at 14:16
  • 2
    Dangit, I should've used a image in my post! :(
    – user160910
    Aug 2, 2013 at 19:09
3

According to this article from Microsoft http://support.microsoft.com/kb/120929 "The system account and the administrator account (Administrators group) have the same file privileges, but they have different functions."

This means that the System Account is the same as a local admin, and it exists for the purpose of running system services with the privileges of an Administrator without requiring a password. The replication process in DFS-R is performed with this account.

The system user has no special significance in the File System or in a DFS setup any different from a regular Admin. However it can become confusing because Windows Admins are not always operating with Administrative privileges depending on how the program or shell was called, whereas a system account would likely always operate with escalated/admin token. I would guess that your DFS setup was just being buggy, and modifying ACLs perhaps caused some syscalls to be made, or file handles to be opened/refreshed that shook the proverbial cobwebs off.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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