Troubleshooting Guide: SQL Server Error 4860 – Bulk Load File Access Failure
Why This Error Happens
Error 4860 occurs when the SQL Server service account cannot locate or access the file specified in a BULK INSERT or OPENROWSET(BULK...) statement. This is typically caused by the file path being inaccessible to the SQL Server service account (as opposed to the user running the query), incorrect UNC/local path syntax, or the file residing on a drive/share that the server process cannot reach due to NTFS permissions or network authentication (double-hop) issues. Additionally, in SQL Server 2025 running on Windows Server 2025, stricter default security policies may block access to mapped drives or local paths that were previously accessible in older OS versions.
Step-by-Step Resolution Guide
Step 1: Verify the File Path and Existence
- Confirm the file actually exists at the exact path specified in the T-SQL command.
- Remember that “file not found” from the client machine does not mean “found” by the server; the path must be valid from the SQL Server’s perspective, not the client’s.
- If using a local path (e.g.,
C:\Data\import.csv), ensure the file resides on the server where the SQL Server instance is actually running, not your local workstation.
Step 2: Check Service Account Permissions
- Open Services.msc on Windows Server 2025 and identify the account running the SQL Server (MSSQLSERVER) service.
- Navigate to the folder containing the target file, right-click Properties > Security.
- Add the SQL Server service account (e.g.,
NT Service\MSSQLSERVERor the custom domain service account) with Read & Execute permissions. - Apply the changes and restart the SQL Server service to ensure permissions are refreshed.
Step 3: Resolve Network Path and Double-Hop Authentication Issues
- If the file is located on a network share (UNC path like
\\FileServer\Share\data.csv), verify that the SQL Server service account has access to that share specifically (Share permissions + NTFS permissions). - If accessing the share triggers a “double-hop” issue (where your Windows login credentials cannot be passed through SQL Server to the remote file server), configure Kerberos Constrained Delegation for the SQL Server service account in Active Directory.
- Alternatively, map network credentials directly on the SQL Server host using the command line:
net use \\FileServer\Share /user:DOMAIN\ServiceAccount Password
Step 4: Check for Container or Sandbox Restrictions
- If running SQL Server 2025 inside a Windows container or with enhanced sandboxing enabled on Windows Server 2025, verify that the data volume is correctly mounted and mapped in the container configuration.
- Ensure the
trace flagor container isolation settings aren’t restricting file system access outside the designated container volume.
Alternative or Verification Steps
- Verify the Fix: Run a simple test query using
BULK INSERT TestTable FROM 'C:\Data\import.csv';after applying permissions. If the command executes without Error 4860, the service account now has the correct access rights. - Alternative Method: If permission issues persist due to strict domain policies, move the source file to the default SQL Server backup/data directory (e.g.,
C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\DATA\), as this location usually already has the correct permissions pre-configured for the service account.