4

This started off simple enough as an issue where we couldn't save changes to existing GPOs. In digging into it, what i have found is that i cannot create or modify any files within the SYSVOL folder.

The error received varies by which application tries to do it, but if i browse to \server\sysvol\domain.com\scripts and right click to create a new text file, the error is "Error 0x8007003A: The specified server cannot perform the requested operation".

I've ruled out and isolated many things so far, but at this point i have no idea.

  • Browsing directly to C:\Windows\SYSVOL to create a file works fine, in any directory
  • I am able to READ all files, and also able to create directories
  • \server\netlogon and \server\sysvol allow file creation/editing, it isn't until i enter \server\sysvol\domain.com that the error comes up.
  • I am aware that domain.com is a junction, i have tried re-creating it with the same result
  • I have confirmed the Share permission is set to Full
  • I have ruled out NTFS errors by 1) checking effective access and 2) the fact that i can create the files on the filesystem without problem, it's only a problem on the share. I also compared the NTFS and share permissions at all levels with a different domain controller (which is working fine).
  • The issue occurs when accessing the share from another computer as well
  • NTFRS is disabled/gone (migrated to DFS-R), and DFS-R is healthy (no errors reported)
  • This is the only domain controller in the environment, all others have been removed cleanly.
  • Turned off Antivirus just to make sure
  • Other shares on the system behave normally
  • Tried accessing via IPv4 address, hostname, fqdn, and IPv6 address, all same result.

I went as far as to run Procmon, but nothing obvious was there. The Explorer.EXE entry is for operation CreateFile, and the result is NAME NOT FOUND. After that entry are some SYSTEM entries, the most telling one probably being operation CreateFile, result 0x8000002D. I have been unable to determine what this result means.

Edit: Thanks to Harry's comment i scrutinized the link a bit more, and it seems that it can be on any share on the system (not just SYSVOL), and only occurs when trying to work within a junction. I'll be digging into this further to see what i can find.

localhost
  • 226
  • 1
  • 6
  • 1
    [0x8000002D - STATUS_STOPPED_ON_SYMLINK - The create operation stopped after reaching a symbolic link.](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/6ab6ca20-b404-41fd-b91a-2ed39e3762ea) Not sure that's very helpful, but FWIW. – Harry Johnston Oct 24 '19 at 07:24
  • You are aware of the distinction between a symbolic link and a directory junction? I'm not sure which of these domain.com is supposed to be, but if you inadvertently replaced one with the other it might cause problems. – Harry Johnston Oct 24 '19 at 23:08
  • Yeah i confirmed it's a junction. Symlinks obviously don't work for clients connecting to the server, but i tested anyways, and they are fine. mklink /j test_junction c:\target - produces same error, but mklink /d test_symlink c:\target - works. – localhost Oct 25 '19 at 16:15
  • Might be worth trying Procmon on both the domain controller and the client simultaneously, find out what if anything is happening from the point of view of the DC's file system when the 0x8000002D error is generated at the client. – Harry Johnston Oct 25 '19 at 21:13
  • And I realize this shouldn't matter for junctions, but perhaps run `fsutil behavior query symlinkEvaluation` on both the client and DC to check that the settings haven't been changed? The first two ("local to local" and "local to remote") should be enabled, the last two ("remote to local" and "remote to remote") should be disabled. – Harry Johnston Oct 25 '19 at 21:17

1 Answers1

2

Ok, finally figured it out! This is caused by FSRM (File Server Resource Manager) and seems to only affect Server 2019, and is most definitely a bug. To fix, you don't have to uninstall FSRM, but you do have to make sure there are no screens setup on the volume containing the junction (C: in cases for SYSVOL), and then reboot the server

FSRM is something that i had ruled out early on, because i deleted the file screen for C: and the issue persisted. What i found out however is that after deleting the file screen you must reboot the server for it to work. There is no part of FSRM (aside from the uninstall process) that prompts/warns for reboot, and you can otherwise make changes to file screens live, so this is definitely a bug.

A few pedantic notes:

  • It does not matter if the screen is set to Passive
  • It does not matter if you manually add exclusions at any level (to the junction, the share, etc.)
  • It does not matter what the content of the file screens are
  • Nothing is ever logged/alerted in FSRM
localhost
  • 226
  • 1
  • 6