Share via

Cannot create new db from restore

James, David (RIS-SUT) 0 Reputation points
2025-10-01T10:38:24.6466667+00:00

Trying to create a new db from a restore. I have OWNER and CONTRIBUTOR roles assigned at subscription scope. The error is

'Authorization failed for template resource the client does not have permission to perform action 'Microsoft.Resources/deployments/write' at scope '/subscriptions/****'

Azure Backup
Azure Backup

An Azure backup service that provides built-in management at scale.

0 comments No comments

2 answers

Sort by: Most helpful
  1. John Funches 5 Reputation points
    2025-10-02T10:33:54.2+00:00

    Classic Azure permission trap! We dealt with the exact same error last week.

    Immediate fix:

    Have the subscription Owner go to Azure Portal → Search "Subscriptions" → Click "My Subscriptions" → Access control (IAM) → Add your account with the "User Access Administrator" role (Owner/Contributor alone aren't enough!)

    If in a hurry, run this PowerShell for forced authorization:

    powershell

    New-AzRoleAssignment
    

    Root cause: Database restoration involves Resource Manager deployments (ARM templates), which require separate administrative permissions. We discovered Tuesday that while Contributor role can manage existing resources, deployment operations require higher privileges.

    Tested solution: Yesterday we temporarily added "User Access Administrator" role for a client and succeeded immediately. Remember to remove this permission after restoration (security best practice). If errors persist, check if subscription-level "Azure Policy" is blocking database creation.

    Was this answer helpful?

    0 comments No comments

  2. Suchitra Suregaunkar 14,595 Reputation points Microsoft External Staff Moderator
    2025-10-02T07:25:29.25+00:00

    Hello James, David (RIS-SUT)

    Thank you for posting your query on Microsoft Q&A portal.

    When attempting “Restore to a new database”, the operation fails with: Authorization failed for template resource. The client does not have permission to perform action 'Microsoft.Resources/deployments/write' at scope '/subscriptions/…'

    Azure SQL restore creates the new DB via an ARM deployment, which requires Microsoft.Resources/deployments/write on the target scope (typically the destination resource group).

    1. The signed‑in principal lacks effective permission for Microsoft.Resources/deployments/write at the destination scope (RG/subscription) used by the restore deployment.
    2. This can occur even if you appear to have Owner/Contributor at subscription level due to:
      • The restore targeting a different resource group or subscription where you don’t have those roles.
      • Deny assignments or policy constraints overriding your role.

    As a workaround assign the below permissions:

    1. Assign a suitable role at the destination scope (prefer Contributor or Owner on the target resource group where the new DB will be created). These roles include Microsoft.Resources/deployments/write and read.
      Reference: Built‑in roles
    2. If you use a custom role, ensure it explicitly includes: Microsoft.Resources/deployments/write and Microsoft.Resources/deployments/read
    3. Check Deny assignments on the destination RG/subscription and remove/adjust if they block deployments. Reference: Check access & role definitions
    4. If restoring across subscriptions/regions, ensure the same permissions exist on that destination as well.
      Reference: Restore options & scopes
    5. Run the restore to a resource group where you already have Contributor/Owner. Use the Azure SQL “Point‑in‑time restore” from the portal blade, choosing a destination RG where your role is effective, this still relies on deployments but helps you choose a scope you control. https://learn.microsoft.com/en-us/azure/azure-sql/database/recovery-using-backups?view=azuresql&tabs=azure-portal

    If the above shared workaround didn't help you then please share us the below details for further investigation.

    1. Which resource group or subscription are you restoring to? is it different from where the backup exists?
    2. Do you have Contributor or Owner role on the target resource group?
    3. Are there any custom RBAC roles assigned instead of built-in roles? (Custom roles might lack Microsoft.Resources/deployments/write.)
    4. Can you check if there are any Deny Assignments or Azure Policies applied to the target resource group or subscription?
    5. Are you restoring to the same region or a different region?
    6. Are you restoring across subscriptions? If yes, confirm roles in both source and target subscriptions.
    7. Can you share the exact restore method?
    8. Do you see any additional error details in the Activity Log?
    9. Are you using your user account or a service principal/managed identity for the restore? (If SPN, check its role assignments.)

    Thanks,

    Suchitra.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.