Loading date from Azure File share

[JonBFabric]

Good Afternoon,

I need to be able to load a number of files from an Azure File share using the SMB protocol, and to use the workspace identity to authenticate. Does anyone have any experience in doing this within Fabric?

Thanks

[bariscihan · Accepted solution]

Hi,

Interesting question — this comes up quite a lot when teams try to treat Azure File Shares like traditional network storage inside Fabric workloads.

From what I’ve tested and seen in current Fabric patterns, there are two important constraints to call out:

1️⃣SMB access + Workspace Identity
Fabric workloads (Notebooks, Pipelines, Dataflows, etc.) currently don’t natively mount SMB shares using Workspace Managed Identity. Fabric is designed to access data through Azure-native data plane integrations (OneLake, ADLS Gen2, Blob, SQL endpoints, etc.), not OS-level network mounts like SMB.

Even if the identity is valid for the storage account, there is no supported mechanism today to:

• Mount Azure Files over SMB inside Fabric compute

• Or authenticate SMB sessions using Workspace Identity

2️⃣Recommended Architecture Pattern
The typical production-safe pattern I’ve seen is:

➡ Azure Files (SMB)
➡ Copy / Sync to ADLS Gen2 or OneLake staging (via ADF, Logic Apps, Azure Function, or Storage sync)
➡ Consume from Fabric via OneLake / ADLS connector

This keeps authentication fully Entra ID + Managed Identity aligned and avoids network layer dependencies.

3️⃣If Real-Time or Near-Real-Time Is Needed
You could consider:

• Azure Function triggered on file arrival → push to ADLS / OneLake

• Storage account event grid → pipeline trigger

• Scheduled Fabric pipeline pulling via REST (if exposing files via another service layer)

4️⃣Edge Option (Not Recommended for Scale)
In theory, a custom compute (VM / AKS) could mount SMB and push data into OneLake — but at that point you’re reintroducing infra that Fabric is trying to abstract away.

---

If your goal is:

• Authentication simplicity → go OneLake / ADLS native

• Zero infra → avoid SMB in Fabric ingestion path

• Enterprise pattern → land → bronze → process (Fabric native)

---

Curious about your scenario:

• Is the Azure File Share coming from a legacy app?

• Or is it acting as a landing zone for vendors / external systems?

If you share that, I can suggest a more concrete pattern.

Note: AI-assisted drafting and structuring. All technical aspects were validated prior to posting.

Thanks!

[v-sgandrathi]

Hi @JonBFabric,

we haven't heard back from you regarding our last response and wanted to check if your issue has been resolved.

Should you have any further questions, feel free to reach out.
Thank you for being a part of the Microsoft Fabric Community Forum!

[v-sgandrathi]

Hi @JonBFabric,

Thank you @tayloramy @deborshi_nag  and @bariscihan  for your response to the query./

We haven’t heard from you on the last response and was just checking back to see if your query was answered.
Otherwise, will respond back with the more details and we will try to help.

Thank you.

[tayloramy · Accepted solution]

Hi @JonBFabric, 

I have not tried this myself, but depending on how you configure the SMB share, it might be possible. 

See Microsoft Entra Kerberos Authentication for Azure Files | Microsoft Learn

Looks like a lot of set up that could potentially break existing access though.  

[deborshi_nag]

Hello @JonBFabric 

Azure Files SMB requires Kerberos, and Microsoft does not support SMB authentication using service principals (Workspace Identity is a service principal). SMB requires:

• A user identity
• A device identity
• Or a managed identity tied to Azure compute (in preview)
  —not a Fabric Workspace Identity.

Therefore, Workspace Identity cannot be used to authenticate to Azure File Shares over SMB.

[bariscihan · Accepted solution]

Hi,

Interesting question — this comes up quite a lot when teams try to treat Azure File Shares like traditional network storage inside Fabric workloads.

From what I’ve tested and seen in current Fabric patterns, there are two important constraints to call out:

1️⃣SMB access + Workspace Identity
Fabric workloads (Notebooks, Pipelines, Dataflows, etc.) currently don’t natively mount SMB shares using Workspace Managed Identity. Fabric is designed to access data through Azure-native data plane integrations (OneLake, ADLS Gen2, Blob, SQL endpoints, etc.), not OS-level network mounts like SMB.

Even if the identity is valid for the storage account, there is no supported mechanism today to:

• Mount Azure Files over SMB inside Fabric compute

• Or authenticate SMB sessions using Workspace Identity

2️⃣Recommended Architecture Pattern
The typical production-safe pattern I’ve seen is:

➡ Azure Files (SMB)
➡ Copy / Sync to ADLS Gen2 or OneLake staging (via ADF, Logic Apps, Azure Function, or Storage sync)
➡ Consume from Fabric via OneLake / ADLS connector

This keeps authentication fully Entra ID + Managed Identity aligned and avoids network layer dependencies.

3️⃣If Real-Time or Near-Real-Time Is Needed
You could consider:

• Azure Function triggered on file arrival → push to ADLS / OneLake

• Storage account event grid → pipeline trigger

• Scheduled Fabric pipeline pulling via REST (if exposing files via another service layer)

4️⃣Edge Option (Not Recommended for Scale)
In theory, a custom compute (VM / AKS) could mount SMB and push data into OneLake — but at that point you’re reintroducing infra that Fabric is trying to abstract away.

---

If your goal is:

• Authentication simplicity → go OneLake / ADLS native

• Zero infra → avoid SMB in Fabric ingestion path

• Enterprise pattern → land → bronze → process (Fabric native)

---

Curious about your scenario:

• Is the Azure File Share coming from a legacy app?

• Or is it acting as a landing zone for vendors / external systems?

If you share that, I can suggest a more concrete pattern.

Note: AI-assisted drafting and structuring. All technical aspects were validated prior to posting.

Thanks!