Error 17113: SQL Server Cannot Find or Open master.mdf at Startup

Fix it now

The service tried to open a file named in its startup parameters, could not, and gave up. The published message says an invalid startup option might have caused it, so read the parameters before you touch permissions. Nothing else can happen until master is readable, and you cannot fix this from Management Studio because there is no instance to connect to.

icacls "D:\MSSQL\DATA" /grant "NT SERVICE\MSSQLSERVER":(OI)(CI)M

1. Read the instance error log in the LOG folder under the instance directory. If the engine could not write it, the Application event log carries the same startup entries.
2. Open SQL Server Configuration Manager, find the instance under SQL Server Services, open its properties and read the Startup Parameters tab. Note the -d, -l and -e values.
3. Check on the server that the files named by -d and -l exist at those exact paths, and that the folder in -e exists. If -e points nowhere the engine cannot write its error log and you lose your best diagnostic.
4. If a path is wrong, correct it in Configuration Manager rather than anywhere else, then start the service.
5. If the paths are right, the operating system error is 5 and the fault is permissions: grant the per-service account Modify on the folder. For a named instance the account is NT SERVICE\MSSQL$INSTANCENAME.

17113 is raised for whichever startup-parameter file failed. master.mdf is the usual one, but the same error appears for mastlog.ldf and for an unwritable error log path.

If the service starts and stays running, you are done. If it starts and stops within seconds, the real error is in the first lines of the newest error log, and the next section explains how to read them.

Why it happens

Startup is a short and strict sequence. The service reads its startup parameters, opens the master data file named by -d and the master log file named by -l, reads the instance configuration out of master, and only then attaches everything else. Because so little exists at that point, the diagnostics are thin: an operating system error number and a path, and that is deliberately all it can say.

The published text of 17113 is worth reading exactly, because it points somewhere most people do not look first. It says an error occurred while opening a file to obtain configuration information at startup, and that an invalid startup option might have caused the error, and it tells you to verify your startup options and correct or remove them if necessary. The startup options are the first suspect, not the last.

17204 is the file-level detail behind the failure, and it carries a piece of information that turns it from a complaint into a diagnosis: the function name printed before the colon. FCB::Open means a file failed to open. FileMgr::StartPrimaryDataFiles, FileMgr::StartSecondaryDataFiles and FileMgr::StartLogFiles each name which stage was running. STREAMFCB::Startup means a FILESTREAM container. 17207 is the broader form of the same thing: an operating system error occurred while creating or opening a file, with the instruction to diagnose and correct the operating system error and retry.

5120 and 5123 are the same class of access failure reported for database files generally, and you meet them when user databases fail to attach even though master opened correctly. An operating system error of 2 or 3 means the path is wrong or the file is not there. An error of 5 means access denied, and the account being denied is the service account, not you. SQL Server runs under a per-service virtual account by default, and permissions granted to it do not travel with the files: restore a folder from backup, copy files to a new volume, or let a security tool reapply inheritance, and the engine loses the access it had yesterday while the files themselves are intact.

Full reference

Which failure you have

The startup options that matter here

The distinction between -c and -f is worth getting right, because they are often quoted together as if they were one thing. -f is what you use when a configuration value such as over-committed memory is preventing startup, and it forces single-user mode as a side effect. -c only affects how the process starts from a command prompt. The pair you want for a master restore is -m.

Reading the function name in a 17204

If the entry names a user database, master opened successfully and the instance is running: what you have is a database that will sit in RECOVERY_PENDING, not an instance that will not start. That single distinction changes the urgency and the fix.

Rebuilding, and what it costs

Rebuilding the system databases replaces master, model and msdb with fresh copies. Logins, permissions, SQL Agent jobs, linked servers and every instance-level setting revert to defaults, and the only way back is a restore of those databases. Copy the existing files aside before you run setup, even if you believe them to be unusable.

1. Copy the whole DATA folder aside with the instance stopped.
2. Run SQL Server setup and use the action that rebuilds the system database files for the instance.
3. Start the instance and confirm it comes up with a default configuration.
4. Restore master using the documented single-user sequence, which needs the instance started with -m.
5. Restore msdb to recover jobs, operators, alerts and backup history.
6. Reattach user databases, then re-check logins, permissions and anything that lived at instance level.

Every code this article covers

Confirm the fix worked

1. Confirm the service is running in SQL Server Configuration Manager and stays running after a restart of the server.
2. Connect and confirm the instance identifies itself correctly: SELECT @@SERVERNAME, SERVERPROPERTY('ProductVersion');
3. Confirm every database came online: SELECT name, state_desc FROM sys.databases;
4. Read the newest error log from the top and confirm master, model, msdb and tempdb all started without file errors.
5. Confirm the -e path is writable, so the next failure leaves you a log to read.

Questions people ask about this