CREATE DATABASE Permission Denied (Error 262)

262 is the engine’s generic permission-denied message. The verb changes, the shape stays the same: the catalog holds it as %ls permission denied in database '%.*ls'., and the statement you ran fills in both blanks. CREATE DATABASE is the version most people meet first, usually the day a new tool or a new starter tries to create their first database.

It is also one of the easier errors on this site to fix well, because the interesting question is not how to make it go away. Membership in sysadmin makes every 262 go away. The question is which of the three narrower grants fits the login in front of you, and all three are below, each one run and confirmed on a real instance.

Why It Says master When You Were Not In master

You can run CREATE DATABASE from any database context. The permission check still lands in master, because creating a database is a server-level operation and master is where that permission lives. The database named in the message is where the check failed, not where you were sitting.

The same template covers object-level verbs too, and then the message names the database you are working in. Both of these are the same Msg 262, raised at Level 14:

To see what the login actually holds at server level, run this as the login that failed, or under EXECUTE AS LOGIN if you are checking on someone else’s behalf:

SELECT permission_name
FROM   fn_my_permissions(NULL, 'SERVER')
ORDER  BY permission_name;

Three Grants That Fix It, and What Each One Really Hands Over

All three of these were run against SQL Server 2025 while writing this, each from a login that had just produced the error. Every one clears it. They are not interchangeable, because each carries a different amount of extra authority:

The server-level grant is the one I reach for when a deployment tool or a service login needs to create databases and nothing more:

GRANT CREATE ANY DATABASE TO [app_deploy];

The master-scoped version does the same job for the single-database case and reads more explicitly in an audit:

USE master;
CREATE USER [app_deploy] FOR LOGIN [app_deploy];
GRANT CREATE DATABASE TO [app_deploy];

And dbcreator fits a person rather than a process, someone who will also restore and drop what they create. Grant it knowingly, because it applies to every database on the instance, not just theirs:

ALTER SERVER ROLE dbcreator ADD MEMBER [jane_dba];

The Login Owns What It Creates

Whichever grant you choose, the login that runs CREATE DATABASE becomes the owner of the new database. I checked this while writing the fixes above: create a database from a barely-privileged login and sys.databases shows that login as owner, mapped inside the database as dbo.

That matters later. Ownership feeds ownership chaining, and a database owned by a personal login outlives the person, which is how you end up with databases owned by logins that no longer exist. Many teams standardise the owner immediately after creation:

ALTER AUTHORIZATION ON DATABASE::Reporting TO sa;

916 Is the Same Conversation, One Door Earlier

While testing the CREATE TABLE variant for this post, the first error back was not 262 at all. A login with no user in the target database gets Msg 916, “not able to access the database”, before any permission on the verb is even considered. Map the user in, run it again, and then you get 262.

The two make a clean pair: 916 means you never got through the database door. 262 means you are inside and lack the specific verb. If you are triaging someone else’s failure, that ordering tells you which fix to start with.

What Not To Do

• Do not reach for sysadmin. It clears every 262 and every other permission error forever, which is exactly why it is the wrong answer to a specific missing grant. The three fixes above are all one line each.
• Do not confuse this with a failing RESTORE. Restores that fall over report their own chain ending in 3013, covered separately, and granting create permissions on a hunch will not move you forward there.
• Do not grant and forget. A one-off grant made to unblock a Tuesday has a way of surviving for years. If you cannot say who holds create rights on an instance, the audit scripts below will tell you.

Common Questions

Related Scripts

• Get Permissions and Role Membership, the full picture of who holds what, including server-level grants like CREATE ANY DATABASE
• Get Sysadmin Members, worth running after any incident that tempted someone to solve a 262 the wide way
• Get Login Security Audit, the wider login hygiene check