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

Question

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

Michelle 0

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

Erland Sommarskog 134K Reputation points MVP Volunteer Moderator

2026-04-28T21:24:49.1533333+00:00

This certainly sounds like a double-hop problem, which I am very good at. My friend David Postlewaite has a presentation about this, which you can view here. Although that session is more directed on issues with linked server, and I don't think he talks directly about BULK INSERT.

A note: The configuration option ad hoc distributed queries enabled has nothing to do with this, and I recommend that you keep it disabled. If you are using OPENROWSET for anything else but BULK, you will needed, but in that case you should try to have those occurrences removed and replaced with regular linked servers.
Michelle 0 Reputation points

2026-04-30T06:47:08.9666667+00:00

Hi @Erland Sommarskog I have covered everything in David's video. I am unsure at this point if this is a limitation of BULK INSERT command or bug in SQL 2022. I'd be interested to know if it works for you in your environment in a double hop situation.

Also, thanks for the advice regarding ad hoc distributed queries. I enabled it as I initially tested with OPENROWSET but had trouble with that too so will disable it again.
Erland Sommarskog 134K Reputation points MVP Volunteer Moderator

2026-04-30T19:51:11.52+00:00

I'd be interested to know if it works for you in your environment in a double hop situation.

No, it doesn't, but here at home, I don't have a domain, no Kerberos, SPNs etc, I don't expect it to. At work, there is a domain, but double hops for linked servers works so-so. (I'm in a developer role and not responsible for setting up servers in general.)

One thing you can try is to grant the machine account DOMAIN\MACHINE$ read access to the file share. I like to point out that even if it works it is not a good solution from a security standpoint.
Michelle 0 Reputation points

2026-05-01T01:33:27.66+00:00

Oh I've tried giving the machine account access to the file share too... but the procedure doesn't even appear to be trying to make the connection hence why I feel like it a limitation of bulk insert.
Erland Sommarskog 134K Reputation points MVP Volunteer Moderator

2026-05-01T08:55:03.1533333+00:00

When you are logged in with Windows authentication, and you run BULK INSERT or OPENROWSET(BULK), SQL Server will impersonate you, and your permissions will apply for the file. If the file is on a remote server, delegation must have been configured correctly. If you are logged in with SQL authentication, SQL Server will use the credentials of itself, that is, the service account for SQL Server. You can read more about this here: https://learn.microsoft.com/en-us/sql/relational-databases/import-export/import-bulk-data-by-using-bulk-insert-or-openrowset-bulk-sql-server?view=sql-server-ver17#security-considerations

As you can see, the scenario you have is certainly supported, but getting all stars aligned certainly can be difficult.

A last resort would be to open a support case, although it could cost your organisation an arm and a leg.
Akhil Gajavelly 1,820 Reputation points Microsoft External Staff Moderator

2026-05-04T06:09:36.01+00:00
Hi @Michelle ,

Thanks for the detailed follow-ups especially the point that no CIFS ticket/request is even being attempted during BULK INSERT. That’s a really key observation.

Given everything you’ve already validated (Kerberos, delegation including RBCD, SPNs, and the fact that xp_cmdshell works), this does not look like a standard delegation misconfiguration anymore.

The behavior you’re seeing where BULK INSERT doesn’t even attempt to access the file server in a remote execution context strongly suggests it’s tied to how SQL Server is handling the impersonated token for BULK operations, rather than environment setup.

At this point, I’d agree this is either,

a limitation in BULK INSERT with double-hop scenarios, or

something specific to SQL Server 2022 behavior

Since you’ve already ruled out the usual causes, the best next step would be to raise this with Microsoft support so it can be validated as a product limitation or bug.

If you do get confirmation either way, it would be great if you could share it back here it would definitely help others hitting similar scenarios.

Thanks,
Akhil.
Akhil Gajavelly 1,820 Reputation points Microsoft External Staff Moderator

2026-05-12T08:08:45.3466667+00:00

HI @Michelle ,

Just following up to see if there were any updates from Microsoft support on this issue.

Based on the troubleshooting already completed, this appeared to go beyond a normal Kerberos/delegation configuration problem, especially since BULK INSERT never attempted SMB/CIFS access in the remote execution scenario while xp_cmdshell worked correctly.

If you were able to confirm whether this is a SQL Server 2022 limitation or a product bug, sharing the outcome here would definitely help others facing similar double-hop BULK INSERT behavior.

Thanks,
Akhil.
Erland Sommarskog 134K Reputation points MVP Volunteer Moderator

2026-05-12T20:43:58.1766667+00:00
So I played a little with this. If I first verified that delegation worked for a linked server. That is, I was running SSMS on server A, connected to server B and ran a linked-server query against server C. That worked. Then I tried to run BULK INSERT against a file on a share on server C. That did not work, but I got the same error as Michelle.

Out of curiosity, I asked around "Is this supposed to work?", and I got this answer from a contact at Microsoft:

Yeah, this is expected, it’s really more about Kerberos delegation for file shares than anything specific to BULK INSERT. What’s happening is the classic double-hop: you connect from A to B, and then B tries to access C on your behalf. Whether that works depends on which services on C are allowed for delegation. In your setup, B is talking to two different services on C:

SQL Server (via the linked server)

The file share (via SMB for BULK INSERT) Delegation is already set up for SQL Server on C, which is why the SELECT works. The file share isn’t included, so when BULK INSERT tries to open the file as you, it gets denied. To change it, you just need to update delegation on the SQL Server service account on B and add the file service for C. You should end up with both:

MSSQLSvc/C.fqdn:1433 (or your instance/port)

cifs/C.fqdn (or HOST/C.fqdn) A couple things to keep in mind:

Constrained delegation still respects the user’s permissions on C.

If A -> B isn’t already using Kerberos, you may need “Use any authentication protocol.”

Make sure the user isn’t marked as “sensitive and cannot be delegated.” The behavior should be the same independent of SQL version. Yeah, this is expected, it’s really more about Kerberos delegation for file shares than anything specific to BULK INSERT. What’s happening is the classic double-hop: you connect from A to B, and then B tries to access C on your behalf. Whether that works depends on which services on C are allowed for delegation. In your setup, B is talking to two different services on C:

SQL Server (via the linked server)

The file share (via SMB for BULK INSERT) Delegation is already set up for SQL Server on C, which is why the SELECT works. The file share isn’t included, so when BULK INSERT tries to open the file as you, it gets denied. To change it, you just need to update delegation on the SQL Server service account on B and add the file service for C. You should end up with both:

MSSQLSvc/C.fqdn:1433 (or your instance/port)

cifs/C.fqdn (or HOST/C.fqdn) A couple things to keep in mind:

Constrained delegation still respects the user’s permissions on C.

If A -> B isn’t already using Kerberos, you may need “Use any authentication protocol.”

Make sure the user isn’t marked as “sensitive and cannot be delegated.” The behavior should be the same independent of SQL version.

I understand from your original post that you have more or less tried this already, but maybe you have missed something somewhere.

No, I did not try this myself. I don't know if I have the rights to play with delegation, but even if I have it is definitely outside the scope from what I am supposed to do on these servers. (I'm not a DBA; but a systems developer.) However, my gut feeling is that, yes, you can do this with BULK INSERT if you configure everything correctly. The reason I think so is that I expect this to be a common thing that people want to do. So if it does not work at all, I would expect to see more questions about it.

I hope you have followed our advice to open a support case, and maybe the issue is already resolved by now. But I still wanted to make this update.

3 answers

Your answer

Erland Sommarskog 134K Reputation points MVP Volunteer Moderator

2026-04-28T21:24:49.1533333+00:00

This certainly sounds like a double-hop problem, which I am very good at. My friend David Postlewaite has a presentation about this, which you can view here. Although that session is more directed on issues with linked server, and I don't think he talks directly about BULK INSERT.

A note: The configuration option ad hoc distributed queries enabled has nothing to do with this, and I recommend that you keep it disabled. If you are using OPENROWSET for anything else but BULK, you will needed, but in that case you should try to have those occurrences removed and replaced with regular linked servers.
Michelle 0 Reputation points

2026-04-30T06:47:08.9666667+00:00

Hi @Erland Sommarskog I have covered everything in David's video. I am unsure at this point if this is a limitation of BULK INSERT command or bug in SQL 2022. I'd be interested to know if it works for you in your environment in a double hop situation.

Also, thanks for the advice regarding ad hoc distributed queries. I enabled it as I initially tested with OPENROWSET but had trouble with that too so will disable it again.
Erland Sommarskog 134K Reputation points MVP Volunteer Moderator

2026-04-30T19:51:11.52+00:00

I'd be interested to know if it works for you in your environment in a double hop situation.

No, it doesn't, but here at home, I don't have a domain, no Kerberos, SPNs etc, I don't expect it to. At work, there is a domain, but double hops for linked servers works so-so. (I'm in a developer role and not responsible for setting up servers in general.)

One thing you can try is to grant the machine account DOMAIN\MACHINE$ read access to the file share. I like to point out that even if it works it is not a good solution from a security standpoint.
Michelle 0 Reputation points

2026-05-01T01:33:27.66+00:00

Oh I've tried giving the machine account access to the file share too... but the procedure doesn't even appear to be trying to make the connection hence why I feel like it a limitation of bulk insert.
Erland Sommarskog 134K Reputation points MVP Volunteer Moderator

2026-05-01T08:55:03.1533333+00:00

When you are logged in with Windows authentication, and you run BULK INSERT or OPENROWSET(BULK), SQL Server will impersonate you, and your permissions will apply for the file. If the file is on a remote server, delegation must have been configured correctly. If you are logged in with SQL authentication, SQL Server will use the credentials of itself, that is, the service account for SQL Server. You can read more about this here: https://learn.microsoft.com/en-us/sql/relational-databases/import-export/import-bulk-data-by-using-bulk-insert-or-openrowset-bulk-sql-server?view=sql-server-ver17#security-considerations

As you can see, the scenario you have is certainly supported, but getting all stars aligned certainly can be difficult.

A last resort would be to open a support case, although it could cost your organisation an arm and a leg.
Akhil Gajavelly 1,820 Reputation points Microsoft External Staff Moderator

2026-05-04T06:09:36.01+00:00

Hi @Michelle ,

Thanks for the detailed follow-ups especially the point that no CIFS ticket/request is even being attempted during BULK INSERT. That’s a really key observation.

Given everything you’ve already validated (Kerberos, delegation including RBCD, SPNs, and the fact that xp_cmdshell works), this does not look like a standard delegation misconfiguration anymore.

The behavior you’re seeing where BULK INSERT doesn’t even attempt to access the file server in a remote execution context strongly suggests it’s tied to how SQL Server is handling the impersonated token for BULK operations, rather than environment setup.

At this point, I’d agree this is either,

a limitation in BULK INSERT with double-hop scenarios, or

something specific to SQL Server 2022 behavior

Since you’ve already ruled out the usual causes, the best next step would be to raise this with Microsoft support so it can be validated as a product limitation or bug.

If you do get confirmation either way, it would be great if you could share it back here it would definitely help others hitting similar scenarios.

Thanks,
Akhil.
Akhil Gajavelly 1,820 Reputation points Microsoft External Staff Moderator

2026-05-12T08:08:45.3466667+00:00

HI @Michelle ,

Just following up to see if there were any updates from Microsoft support on this issue.

Based on the troubleshooting already completed, this appeared to go beyond a normal Kerberos/delegation configuration problem, especially since BULK INSERT never attempted SMB/CIFS access in the remote execution scenario while xp_cmdshell worked correctly.

If you were able to confirm whether this is a SQL Server 2022 limitation or a product bug, sharing the outcome here would definitely help others facing similar double-hop BULK INSERT behavior.

Thanks,
Akhil.

Answer 1

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

Answer 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

Answer 3

Akhil Gajavelly 1,820 Microsoft External Staff Moderator

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.

Michelle 0 Reputation points

2026-04-28T06:01:49.1533333+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. It still didn't work after restarting SQL services. Does this look right to you?

Get-ADComputer -Identity "FILESERVER" -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |

Select-Object -ExpandProperty msDS-AllowedToActOnBehalfOfOtherIdentity

Path Owner Access

BUILTIN\Administrators DOMAIN\gMSA_SQLService$ Allow

Get-ADServiceAccount -Identity "gMSA_SQLService$" -Properties TrustedForDelegation, TrustedToAuthForDelegation |

Select-Object Name, TrustedForDelegation, TrustedToAuthForDelegation

Name TrustedForDelegation TrustedToAuthForDelegation

gMSA_SQLService False True

Thanks again,

Michelle
Deleted

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

2026-04-28T06:05:08.74+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. It still didn't work after restarting SQL services. Does this look right to you? Get-ADComputer -Identity "FILESERVER01" -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |

Select-Object -ExpandProperty msDS-AllowedToActOnBehalfOfOtherIdentity

Path Owner Access

BUILTIN\Administrators DOMAIN\gMSA_Service$ Allow

Get-ADServiceAccount -Identity "gMSA_Service$" -Properties TrustedForDelegation, TrustedToAuthForDelegation |

Select-Object Name, TrustedForDelegation, TrustedToAuthForDelegation

Name TrustedForDelegation TrustedToAuthForDelegation

gMSA_Service False True

Thanks again,

Michelle
Deleted

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

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

2026-04-28T06:25:14.03+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 our 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

Share via

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

3 answers

Your answer