Share via

BULK INSERT cannot access UNC path, error code 5 (Access is denied) using gMSA unless locally triggered

Michelle 0 Reputation points
2026-04-28T02:03:11.9766667+00:00

Running a stored procedure to bulk insert from a UNC path works locally via SSMS and via SQL agent job but if run remotely I receive Operating system error code 5 (access is denied). Please help as this workaround is not suitable for our environment.

Environment is SQL Server 2022 Standard Edition RTM-CU24 (16.0.4245.2)

Symptoms:

  • BULK INSERT fails with Operating system error code 5 (Access is denied) on UNC path
  • xp_cmdshell accessing identical UNC path as same gMSA succeeds
  • OPENROWSET(BULK) fails with same error
  • Works when SSMS is run locally on SQL Server
  • Works when executed via SQL Agent job
  • No cifs/ service ticket for target file server is requested during BULK INSERT
  • Manually pre-caching cifs/FILESERVER ticket via xp_cmdshell pushd does not resolve the issue

Confirmed working:

  • gMSA Test-ADServiceAccount returns True
  • NTFS and share ACLs grant gMSA Full Control
  • cifs/ SPNs exist on both SQL Server (MSSQLSvc) and file server
  • Constrained delegation configured on gMSA for cifs/ of file server and DFS namespace servers
  • Client to SQL connection confirmed Kerberos (not NTLM)
  • ad hoc distributed queries enabled
  • allow filesystem enumeration enabled
  • xp_cmdshell can list and access the file as gMSA
  • Local file BULK INSERT works fine

What was tried:

  • Trace flags 4616, 4032 - nothing of interest logged
  • Constrained delegation configuration
  • cifs SPNs were absent and manually added to file server
  • Pre-cached Kerberos ticket before BULK INSERT

Thanks

SQL Server | SQL Server Transact-SQL
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Michelle 0 Reputation points
    2026-04-28T06:24:17.9866667+00:00

    Thank you Akhil for your insight and suggestions. I have just tried the last option you provided as the others would be too much work to implement across our environment and on an ongoing basis.

    I set fileserver PrincipalsAllowedToDelegateToAccount to the gMSA account and the gMSA account TrustedToAuthForDelegation to $true. It still didn't work after restarting SQL services. Did I miss something?

    Thanks again,

    Michelle

    0 comments
  2. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

  3. Akhil Gajavelly 1,820 Reputation points Microsoft External Staff Moderator
    2026-04-28T04:10:52.9033333+00:00

    Hi @Michelle ,

    This doesn't look like a permission or gMSA issue your xp_cmdshell test already proves the account can access the share. The real issue is that BULK INSERT uses the impersonated remote client's security token for file I/O, not the gMSA's OS-level Kerberos session. That token is a non-forwardable network logon token, so no CIFS ticket is even negotiated hence the error code 5. That's why local execution and SQL Agent (no delegation needed) both work fine.

    Try bellow few Practical options.

    • SQL Agent job via sp_start_job wraps the procedure, avoids the hop
    • BCP via xp_cmdshell since you've confirmed xp_cmdshell works, BCP runs as a real OS process under the gMSA and sidesteps the thread impersonation issue entirely
    • RBCD on the file server configure Resource-Based Constrained Delegation on the file server computer object to trust the SQL gMSA, and ensure TrustedToAuthForDelegation is set on the gMSA for protocol transition (S4U2Self). This is the clean fix if you want BULK INSERT to work as-is without workarounds.

    Thanks,
    Akhil.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.