“Could not create tempdb” after an Azure VM restart often means SQL Server started before the ephemeral disk, target folder, or permissions were restored. Confirm every configured tempdb path, prepare the drive, and only then start the SQL Server service.
Last updated: October 30, 2026.
SELECT
name,
physical_name,
size * 8 / 1024 AS size_mb
FROM sys.master_files
WHERE database_id = 2
ORDER BY file_id;Run this query while the instance is healthy and keep the result with the server configuration. Every listed data and log path must exist and be writable by the SQL Server service account before the next startup.
Prepare ephemeral storage before SQL Server starts
Azure local SSD storage is ephemeral: its contents and permissions can disappear when a VM is deallocated, moved, resized, or repaired. Microsoft’s guide to placing tempdb on ephemeral storage recommends setting SQL Server and SQL Server Agent to manual start when a custom startup task must initialize the drive.
The startup task should wait for the drive, initialize it when required, create the configured folder, grant the SQL Server service account access, and then start SQL Server followed by SQL Server Agent. Run the task whether or not an administrator is logged on.
Use a persistent fallback when necessary
If the VM type does not reliably expose initialized temporary storage, move tempdb to a suitable persistent disk during a maintenance window. Microsoft also documents a drive-not-ready startup failure caused by RAW or unavailable local SSD storage.
After recovery, verify all files with sys.master_files, check the SQL Server error log, and test a full VM restart. Do not place user databases, logs, or backups on ephemeral storage. Continue with moving SQL Server files safely, recovering a suspended SQL Server operation, and checking Availability Group health.
