How to fix Error 5183 on Windows Server 2025 / Windows 11

by

Troubleshooting Guide: SQL Server Error 5183 During Database Restore

Why This Error Happens

Error 5183 occurs when SQL Server attempts to restore a database but encounters a conflict with the physical file paths specified in the backup. This typically happens because the target file path or file name already exists on disk (often from a previous restore attempt or an existing database with the same logical file names), or because the original file paths stored in the backup header do not exist on the destination server. Without explicit instructions via WITH MOVE or WITH REPLACE, SQL Server refuses to overwrite or redirect files to avoid accidental data loss.

Step-by-Step Resolution Guide

Step 1: Identify the Logical and Physical File Names in the Backup

  • Run the following command to inspect the backup file structure before restoring:
RESTORE FILELISTONLY FROM DISK = 'C:\Backups\YourDatabase.bak';
  • Note the LogicalName and PhysicalName columns returned — you will need the LogicalName values for the next step.
  • Check if the PhysicalName paths (e.g., D:\SQLData\YourDB.mdf) already exist on the target server, as this is the most common trigger for Error 5183.

Step 2: Restore the Database Using WITH MOVE

  • Use the MOVE clause to redirect the data (.mdf) and log (.ldf) files to new, valid paths on Windows Server 2025 or Windows 11:
RESTORE DATABASE YourDatabase
FROM DISK = 'C:\Backups\YourDatabase.bak'
WITH MOVE 'YourDB_Data' TO 'D:\SQLData\YourDatabase.mdf',
     MOVE 'YourDB_Log' TO 'E:\SQLLogs\YourDatabase_log.ldf',
     REPLACE;
  • Ensure the destination directories (D:\SQLData\ and E:\SQLLogs\) actually exist; SQL Server will not auto-create folders.
  • Verify the SQL Server service account (e.g., NT Service\MSSQLSERVER) has Modify permissions on these target folders via Windows file security settings.

Step 3: Resolve File Conflicts if a Database Already Exists

  • If a database with the same name and file paths already exists, add the REPLACE option to explicitly overwrite it:
RESTORE DATABASE YourDatabase
FROM DISK = 'C:\Backups\YourDatabase.bak'
WITH REPLACE;
  • If the existing database is still attached and in use, take it offline first using SQL Server Management Studio (SSMS) or run:
ALTER DATABASE YourDatabase SET OFFLINE WITH ROLLBACK IMMEDIATE;
  • Delete or rename any orphaned .mdf/.ldf files left on disk from a failed previous restore attempt before retrying.

Step 4: Check Folder Permissions and Disk Space

  • Open File Explorer, right-click the target data/log folder, select Properties > Security, and confirm the SQL Server service account has Full Control or Modify rights.
  • Verify sufficient free disk space exists on the target drive using Get-PSDrive in PowerShell, since insufficient space can also trigger file creation failures that masquerade as path conflicts.

Alternative or Verification Steps

  • After the restore completes, run RESTORE VERIFYONLY FROM DISK = 'C:\Backups\YourDatabase.bak'; beforehand on future attempts, and confirm the database shows as Online in SSMS under Databases with no error icons.
  • If the error persists, use SSMS’s graphical restore wizard (Right-click Databases > Restore Database > Files tab) to manually edit the restore-as paths, which auto-populates valid MOVE paths and avoids manual syntax errors.