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

[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]

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.

Thanks!