Upload CSV from Powershell to Lakehouse

throwserror  

What’s Going Wrong

You're using client credentials flow to get an access token for OneLake, but you're not seeing any roles in the token payload. That’s expected behavior for this flow unless you're using role-based access control (RBAC) via Microsoft Entra ID (formerly Azure AD) and have explicitly assigned app roles or API permissions to your app registration.

The key issue: Storage Blob Data Contributor and Storage Account Contributor are Azure RBAC roles, but OneLake in Microsoft Fabric doesn't use traditional Azure Storage RBAC directly. Instead, it uses Microsoft Fabric-specific permissions and Entra ID scopes.

Recommended Fixes and Alternatives

1. Use Connect-AzAccount Instead of Client Credentials

If you're just uploading files manually via PowerShell, the simplest route is to use interactive login:

Install-Module Az.Storage -Force Connect-AzAccount $ctx = New-AzStorageContext -StorageAccountName "onelake" -UseConnectedAccount -Endpoint "fabric.microsoft.com" Set-AzDataLakeGen2ItemContent -Context $ctx ` -FileSystem "" ` -Path ".lakehouse/Files/Daily_Report_XXX.csv" ` -Source "C:\taod_export\Daily_Report_XXX.csv"



This avoids the whole token dance and uses your signed-in identity, which already has access to the workspace.

Reference: Microsoft’s PowerShell guide for OneLake

2. If You Must Use Client Credentials

Then you need to:

• Register your app in Microsoft Entra ID
• Assign API permissions like Storage delegated access or Files.ReadWrite.All
• Use delegated permissions if possible (requires user context)
• Or configure app roles and assign them to your app

But this is complex and not well-supported for OneLake yet. The REST API is still evolving, and many operations expect user context, not app-only tokens.

3. Use AzCopy with Entra ID Auth

If you're automating uploads, consider using AzCopy with Entra ID. It supports OneLake and handles token acquisition and permissions more gracefully.

What to Test Next

• Try switching to Connect-AzAccount and New-AzStorageContext for a quick win
• If you must use client credentials, inspect the token’s scp (scope) claim—not just roles
• Check whether the Fabric workspace has granted access to your app via Microsoft Fabric Admin Portal
• Use the Purple Frog PowerShell script as a reference—it’s tailored for OneLake uploads

Hi throwserror ,

Thanks for posting in Microsoft Fabric Community.

As anilgavhane  already mentioned, the behavior you see with the token not containing roles is expected when using client credentials. What matters for OneLake is not Azure Storage RBAC but permissions within the Fabric workspace. The service principal must be added as a Member, Contributor, or Admin in the Fabric workspace itself, since Fabric manages its own access model and does not honor Azure RBAC roles.

Also, when requesting the token, please make sure the scope is set to https://onelake.dfs.fabric.microsoft.com/.default instead of https://storage.azure.com/.default.

Using the storage endpoint scope is valid for Azure Storage accounts, but OneLake requires its own scope.

For more details on SPNs: Service Principals in Fabric Data Warehouse - Microsoft Fabric | Microsoft Learn

In addition, for service principal access to work, the following tenant settings need to be enabled by a Fabric admin:

1. Service principals can call Fabric public APIs

2. Users can access data stored in OneLake with apps external to Fabric

Hope this helps. Please reach out for further assistance.

Thank you.

Also thanks to anilgavhane for detailed explanation and for sharing useful resources.