Troubleshooting Guide: SQL Server Error 4886 — “Cannot Open the File”
Why This Error Happens
Error 4886 typically occurs when SQL Server 2025 is unable to access a backup, data, or log file due to restrictive NTFS permissions on the file or its parent directory. This can also result from the file being locked by another process (such as an antivirus scanner or a stale backup job), or because the file path is incorrect or the file has been moved, renamed, or deleted outside of SQL Server’s control. Additionally, in containerized or clustered Windows Server 2025 environments, a disconnected network share or an expired SMB session can trigger this same underlying I/O failure.
Step-by-Step Resolution Guide
Step 1: Verify File Path and Existence
- Confirm the exact file path referenced in the error message (%ls) actually exists on disk.
- Open File Explorer or run
dir "D:\SQLData\YourFile.bak"in Command Prompt to validate the path. - Check for hidden path issues such as trailing spaces, incorrect drive letters, or mapped network drives that aren’t available to the SQL Server service account.
Step 2: Check and Correct NTFS Permissions
- Right-click the folder containing the file, go to Properties > Security > Edit.
- Ensure the SQL Server service account (e.g.,
NT Service\MSSQLSERVERor a custom domain service account) has Full Control or at minimum Modify and Read/Write permissions. - Run this PowerShell command to grant permissions programmatically:
icacls "D:\SQLData" /grant "NT SERVICE\MSSQLSERVER:(OI)(CI)F" /T
- Restart the SQL Server service after applying permission changes via
services.msc.
Step 3: Release File Locks and Check for Conflicting Processes
- Use Resource Monitor (
resmon.exe) or Process Explorer to identify if another process (antivirus, backup agent, or a stale SQL session) has an open handle on the file. - Temporarily disable real-time antivirus scanning on the SQL data/log directories, or add exclusions for
.mdf,.ldf, and.bakfile types. - If the file is a backup file and still in use by an incomplete
BACKUPorRESTOREoperation, kill the related SPID usingKILL <session_id>in SSMS.
Step 4: Validate Disk Health and Storage Connectivity
- If using shared storage (SAN, NAS, or SMB share), confirm the volume is online and reachable using
Test-NetConnectionorGet-Diskin PowerShell. - Run
chkdsk D: /f(on the affected volume) during a maintenance window to rule out underlying disk corruption. - For cluster or Always On Availability Group setups, verify the storage resource is online in Failover Cluster Manager.
Alternative or Verification Steps
- After applying the fix, attempt the original operation again (e.g., re-run the
BACKUP DATABASEorRESTORE DATABASEcommand) and confirm no errors are returned in SSMS or the SQL Server Error Log. - If the issue persists, as an alternative, move the file to a local, non-shared drive with verified permissions (e.g.,
C:\Temp\SQLBackups) to isolate whether the problem is permissions-based or storage/network-based.