Error when running debug on a pipeline in synapse

Question

Error when running debug on a pipeline in synapse

MrFlinstone 706

I have got a sink destination for a synapse analytics pipeline, works well with the storage account setup with synapse, however I am trying to change the sink destination to a different storage account, anytime I do that and run the pipeline in debug mode, I get the error below.

Job failed due to reason: at Sink 'PipelineName': Not able to validate external location because The remote server returned an error: (403) Forbidden.. Details:shaded.msdataflow.com.microsoft.sqlserver.jdbc.SQLServerException: Not able to validate external location because The remote server returned an error: (403) Forbidden

the linked service which is a storage account data lake has access via a managed identity, the manage identity has storage data contributor role assigned on the storage account. I got referred to the link https://learn.microsoft.com/en-gb/azure/data-factory/connector-azure-data-lake-storage?tabs=data-factory#managed-identity

When I look under system assigned manged identity, I can see the instructions

As source: In Storage Explorer, grant at least Execute permission for ALL upstream folders and the file system, along with Read permission for the files to copy. Alternatively, in Access control (IAM), grant at least the Storage Blob Data Reader role.
As sink: In Storage Explorer, grant at least Execute permission for ALL upstream folders and the file system, along with Write permission for the sink folder. Alternatively, in Access control (IAM), grant at least the Storage Blob Data Contributor role.

I have not had to grant execute permissions as described below for the managed identity that works, however I understand that some permissions may be granted behind the scenes and because the storage account is being changed, this could be the cause of the 403 errors, I am not sure what other roles are required apart from the storage blob data contributor role ?

Thanks in advance.

1 answer

Your answer

Answer 1

Venkat Reddy Navari 5,255 Microsoft External Staff Moderator

Hi MrFlinstone The 403 Forbidden error you're encountering usually indicates a permissions issue with the managed identity on the new storage account. Even though you’ve assigned the Storage Blob Data Contributor role, the pipeline requires specific ACL (Access Control List) permissions on the folders within the Data Lake, especially when using hierarchical namespace (ADLS Gen2).

Based on the official documentation, for the sink, the managed identity needs:

Execute permission on all parent folders (upstream folders and file system).
Write permission on the target sink folder.

Assigning just the Storage Blob Data Contributor role via IAM might not automatically grant these ACL permissions. You can grant these using Storage Explorer or Azure CLI:

Open the target storage account in Storage Explorer.
Navigate to the container and folder where the sink writes data.
Right-click the folder, go to Manage Access or Access Control, and add the managed identity with Execute permissions on the folder hierarchy and Write on the sink folder.

If your original storage account “worked without explicitly setting Execute permissions,” it’s likely those permissions were inherited or pre-configured. For the new storage account, explicitly setting these ACL permissions should resolve the 403 error.

Also, double-check:

The managed identity you configured is the one used by the Synapse pipeline’s linked service.
The linked service’s authentication is set to use the managed identity properly.
No firewall or network restrictions block access to the new storage account

Hope this helps. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

MrFlinstone 706 Reputation points

2025-08-07T13:00:49.7066667+00:00

What is surprising is that the managed identity that works doesn't explicitly have ACL read/write/execute permissions on the container folders, always hesitant to add new permissions unless one understands why as it could just be creating holes in the environment.

Is there a way to check existing ACL permissions on specific containers.
Venkat Reddy Navari 5,255 Reputation points Microsoft External Staff Moderator

2025-08-08T14:24:30.9433333+00:00
Hi MrFlinstone To check existing ACL permissions on containers or folders:

You can use either of the following:

Azure CLI

Use this command to inspect current ACLs:

az storage fs access show \ --account-name <your-storage-account> \ --file-system <your-container-name> \ --path <folder-path> \ --auth-mode login

This will return the list of identities and their assigned Read/Write/Execute permissions on the specified path.

Azure Storage Explorer

Navigate to the container/folder.

Right-click → Manage Access.

View current Access Control Entries (ACEs) applied to the path.

This should help clarify whether the managed identity has explicit permissions or if they were inherited.

Hope this helps. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.
Venkat Reddy Navari 5,255 Reputation points Microsoft External Staff Moderator

2025-08-11T11:52:01.1133333+00:00

MrFlinstone Following up to see if the above answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

Share via

Error when running debug on a pipeline in synapse

1 answer

Your answer