Host reports 403 AuthorizationPermissionMismatch on Blobs with correct RBAC, indexes no functions, and reports nothing to App Insights

[ismaelocaramelo]

Investigative information

• Timestamp: 2026-08-21, ~09:20–13:55 UTC
• Function App version: host 4.1052.300.0, FUNCTIONS_EXTENSION_VERSION=~4
• Region: West Europe
• Runtime: NODE|24, Linux, kind: functionapp,linux
• Plan: Basic B1 (dedicated), alwaysOn: true
• Storage connection: identity-based, system-assigned managed identity

Summary

A Function App host reaches state: Error with a single 403 AuthorizationPermissionMismatch
against Blob Storage, and therefore indexes no functions at all — az functionapp function list
returns empty — while the site reports Running and the package is deployed on disk.

The identity holds Storage Blob Data Owner, Storage Queue Data Contributor and Reader on the
target storage account, with no ABAC conditions and no deny assignments. The host's own
internal containers (azure-webjobs-hosts, azure-webjobs-secrets) do exist in that account,
which means blob access worked at least once.

The same ARM template, same runtime, same role set, deployed to a different subscription, works
correctly and indexes its function.

Repro steps

1. Deploy, from one ARM/Bicep template, a Linux Function App on a dedicated B1 plan alongside a
   storage account, with AzureWebJobsStorage configured for identity:
   • AzureWebJobsStorage__accountName
   • AzureWebJobsStorage__blobServiceUri
   • AzureWebJobsStorage__queueServiceUri
2. In the same deployment, create role assignments for the app's system-assigned identity on the
   storage account: Storage Blob Data Owner, Storage Queue Data Contributor, Reader.
3. Deploy code with az functionapp deployment source config-zip (a pre-built bundle; no remote build).
4. Restart the app and query GET /admin/host/status.

Expected behavior

The host starts and indexes the functions declared by the deployed package (a single blob-triggered
function, Node v4 programming model).

Actual behavior

state: Error
version: 4.1052.300.0
errors: 1
  Azure.Storage.Blobs: This request is not authorized to perform this operation using this permission.
  RequestId: 535edfec-801e-00d8-7269-310f07000000
  Time: 2026-08-21T12:32:06.7484680Z
  Status: 403 (This request is not authorized to perform this operation using this permission.)
  ErrorCode: AuthorizationPermissionMismatch

Further RequestIds with the same error, in case they help correlate server side:
6d57152f-901e-00eb-2f61-3150ac000000 (11:36:11Z), bc5daf1a-801e-0015-3879-2bcc07000000.

Container log shows a repeating cycle:

Creating container with image: azure-functions/noble/linuxdedicated:4.1052.300-0-node24-appservice
Container is running.
Site startup probe succeeded after 65.5 seconds.
Site is running with deployment version: <guid>
Site started.
Container is terminating. Grace period: 5 seconds.      <-- ~21 s after "Site started"
Container is terminated.
Site: <app> stopped.

What the error does not tell us

The message names Azure.Storage.Blobs but not the operation or the URI, so there is no way from the
outside to know which permission is missing. That is the core of this report: with Storage Blob Data Owner + Reader granted, no conditions and no deny assignments, which blob operation is being
rejected?

Ruled out, with evidence

Hypothesis	How it was ruled out
Missing data-plane roles	all three present, listed by --scope with their assignment IDs
ABAC conditions on the assignments	condition is null on all four assignments on the account
Deny assignments	GET .../providers/Microsoft.Authorization/denyAssignments on the account returns []
Creation path (per #10970)	azure-webjobs-hosts and azure-webjobs-secrets exist — so container creation succeeded
Storage account configuration	identical across 11 fields to the working environment: networkRuleSet.defaultAction: Allow, bypass: None, no IP/VNet rules, allowSharedKeyAccess, publicNetworkAccess, defaultToOAuthAuthentication, minimumTlsVersion, allowBlobPublicAccess, allowCrossTenantReplication, kind, sku
VNet integration	none configured; no VNets in the resource group
Package not deployed	SCM deployment history: status 4 (Success) ×3; rsync of 1,244 files / 12.45 MB reported "Completed successfully"
Missing app settings	full app-setting name set identical to the working environment
Unsupported runtime	the working environment runs the same `NODE
Contention on the shared plan	the co-located web app was deployed and stabilised; symptom unchanged
Deployment order	reproduced with the code deployed as the very last operation
Application Insights as a diagnostic	unusable here: the same query returns zero rows in the working environment too, so its emptiness proves nothing. /admin/host/status was the only source that reported anything

Two observations that may matter

1. Get Blob Service Properties is not covered by the data roles. We add Reader deliberately,
because that service-level read is required at startup and Storage Blob Data Owner does not grant
Microsoft.Storage/storageAccounts/blobServices/read. The documented guidance suggests Storage Account Contributor, which we avoid because it includes listkeys/action — the exact credential path
that identity-based connections exist to remove. If Reader is genuinely insufficient for some other
startup operation, it would help enormously to have that documented, or to have a narrower built-in
role for it.

2. The failure is completely silent from a monitoring standpoint. No telemetry, no failed
executions, state: Running on the site, and a green deployment. The only way we found to detect it
was polling /admin/host/status from a scheduled job. This is the same complaint as #10970, which was
closed — the observability gap it describes is still very much present in 4.1052.300.0.

Related

• App without role assignment to storage silently fails #10970 — same class of silent failure. Our containers exist, so this is not the creation path, but the
  observability problem described there is exactly what made this take a full day to characterise.
• Functions disappear from app after arm template deploy #8189 — ARM template redeploys wiping deployment-tool state and making functions disappear. Different
  mechanism (consumption + WEBSITE_RUN_FROM_PACKAGE), same family of problem.

[ismaelocaramelo]

Adding a duplicate check I did after filing, so triage doesn't have to repeat it. I looked at every
open and closed issue I could find touching identity-based AzureWebJobsStorage, and none of them
matches this one — but three are close enough to be worth linking:

• Intermittent BlobServiceClient creation issue #11787 (closed) — Intermittent BlobServiceClient creation issue. Same component in the stack,
  but a different failure: InvalidOperationException: Unable to find matching constructor, caused by a
  configuration-loading race. Its documented workaround is to set AzureWebJobsStorage__accountName,
  which this app already has alongside __blobServiceUri. Our failure is an authorization 403 from the
  service, not a client-construction failure.

• Intermittent AzureWebJobsStorage failures with Managed Identity on Flex Consumption (host unhealthy + HTTP 401) #11782 (closed) — Intermittent AzureWebJobsStorage failures with Managed Identity on Flex
  Consumption (host unhealthy + HTTP 401). Different plan (FC1 vs dedicated B1), different status code
  (401 vs 403), and intermittent under load rather than a permanent failure that prevents the host from
  ever indexing.

• Event hub trigger does not work using RBAC for AzureWebJobsStorage #9612 (open) — Event hub trigger does not work using RBAC for AzureWebJobsStorage. Same theme of
  RBAC-configured host storage not working, different trigger type and no 403 reported.

Also checked and ruled out as different: #9559 (user-assigned identity via
__managedIdentityResourceId), #11636 (WebJobsStorageHealthCheck warnings when storage is not
configured at all), #10970 and #8189 — the last two are already referenced in the description above.

The distinguishing features of this report, in case they help route it: dedicated plan, system-assigned
identity, permanent rather than intermittent, 403 AuthorizationPermissionMismatch rather than 401,
the host's internal containers already exist (so container creation succeeded at some point), and the
same template works in a different subscription.

[AartBluestoke]

I've noticed 403 errors for ip whitelist failures
It doesn't distinguish
you can't access this, bad user
from
You can't access this, bad ip address

[ismaelocaramelo]

Root cause found: the failing call is SetBlobServiceProperties, and no documented role grants it

I enabled Azure Monitor diagnostic logging on the storage account and restarted the host, so the
server side of every request the host makes is now recorded. Exactly one operation fails.

Operation	Status	Error code	Attempts
ListContainers	200	—	15
GetContainerProperties (azure-webjobs-secrets)	200	—	1
GetBlobProperties (azure-webjobs-secrets/<app>/host.json)	200	—	7
GetBlob (same)	200	—	1
GetBlobServiceProperties	200	—	3
SetBlobServiceProperties	403	AuthorizationPermissionMismatch	3
AcquireBlobLease (azure-webjobs-hosts/locks/<app>/host)	201	—	3
SetBlobMetadata (same)	200	—	3
ReleaseBlobLease (same)	200	—	3
RenewBlobLease (same)	200	—	1

AuthenticationType is OAuth and RequesterObjectId is the Function App's system-assigned identity
on every row, so this is the host's own identity throughout — not another principal.

The whole data plane works. The host reads its secrets, acquires the singleton lease, renews it. The
GetBlobServiceProperties at 200 and the SetBlobServiceProperties at 403 are 150 ms apart: it's a
read-modify-write. The host reads the blob service properties, finds analytics logging disabled, and
tries to enable it — which is what the blob trigger uses to detect new blobs by scanning $logs.

Why the RBAC looked correct, because it was

Microsoft.Storage/storageAccounts/blobServices/write is a control-plane action.

• Storage Blob Data Owner is data-plane. It does not include it.
• Reader includes blobServices/read — which is exactly why the GET returns 200. (I had added
  Reader earlier because without it GetBlobServiceProperties itself returned 403.)
• Storage Queue Data Contributor is unrelated.

Those three roles are what the identity-based AzureWebJobsStorage documentation asks for, and none of
them grants that write. So every RBAC check I ran came back correct — because the RBAC was correct.
That is why this took a week to isolate: the role assignments and the 403 were both right.

Why the same template works in another subscription

In the working environment, analytics logging is already enabled:

write: true, read: false, delete: false, retentionPolicy: { days: 7, enabled: true }

That shape isn't in our IaC — our Bicep never touches these properties, and ARM does not even expose
them. The SDK wrote it, back when that app still used a connection string for AzureWebJobsStorage.
With the property already set, the host reads it, sees what it wants, and skips the write. The failing
environment was identity-based from its first deployment, so it has never been able to set it and
retries on every start.

Worth flagging for anyone else debugging this: az storage account blob-service-properties show goes
through ARM and does not show analytics logging. Compared that way, the two environments look
identical. It only shows up via az storage logging show, which goes through the data plane.

Workaround, applied and confirmed

Set the property once yourself, out of band, so the host finds nothing to change:

az storage logging update --account-name <account> --services b --log w --retention 7

Then restart the app. This is preferable to granting the identity blobServices/write: the only
built-in role that carries it is Storage Account Contributor, which also brings listKeys/action —
the account key — and that is a large amount of extra authority for one property.

I applied it, and it resolved the failure completely. Measured before and after, same app, no other
change:

	before	after
/admin/host/status	state: Error	state: Running
errors reported by the host	1 (the 403)	0
blob-triggered function	never indexed	indexed, trigger registered

The pipeline then processed a real document end to end — blob picked up in about 90 seconds, and the
expected rows written. So the diagnosis holds: this one denied write was the only thing standing
between a host that reports state: Error and a fully working app.

One more thing worth flagging for anyone landing here from a search. After the host recovered, the
management-plane view still disagreed with the host: az functionapp function list returned empty
while GET /admin/functions returned the function with its trigger. Our own health check read the
management-plane view and kept reporting the app as "deployed but inert" for hours after it was fine.
If you are debugging indexing, ask the host — it is the component that indexes.

The product question

Enabling analytics logging is an optimization for blob-trigger latency, not a requirement for the
host to run. Right now a 403 on it appears to be treated as fatal: the host stays in state: Error and
no function of any kind gets indexed — including functions that have nothing to do with blobs.

Two things that would each have saved this investigation:

1. Don't fail host startup when this specific write is denied. Log a warning, fall back to polling.
2. If it must be required, say so in the identity-based AzureWebJobsStorage documentation, and name
   the action (Microsoft.Storage/storageAccounts/blobServices/write) rather than only the three data
   roles — since no combination of those three grants it.

Separately, the host's error surface never names the operation or the URI, which is what forced the
server-side logging detour. Including the operation name in the reported error would make this class of
403 self-diagnosing.