Forum Discussion

fatma_akyol's avatar
fatma_akyol
Frequent Visitor
8 months ago
Solved

Lakehouse sharing without workspace access causes 403

Hello,   We created a OneLake security role and granted access to specific tables.  Then we shared the Lakehouse with the same user using Read and ReadAll permissions via  Lakehouse → Manage perm...
data engineering
  • fatma_akyol's avatar
    fatma_akyol
    7 months ago

    Hello,

    We opened a support ticket with Microsoft. According to their response, workspace permissions are required to view a Lakehouse from the OneLake Catalog and Explorer UI. To open and view Lakehouse tables in the Fabric UI, a user must have one of the following workspace roles: Contributor, Member, or Admin. So the problem is resolved.

deborshi_nag's avatar
deborshi_nag
Icon for Super User rankSuper User
8 months ago

Hello fatma_akyol 

 

Lakehouse sharing should work without giving the user any workspace role—but a 403 can still happen depending on how OneLake security and the SQL Analytics endpoint are configured.
 
  1. Prerequisite for ReadAll
  • ReadAll is an additional permission that only works on top of either Read (item-level sharing) or a workspace Viewer role. You already granted Read (good), so this prerequisite should be satisfied. 
  1. OneLake security (preview) changes the access model
  • If you turned on Manage OneLake security (preview) for the lakehouse, users must be in a data access role to see data; users not in a role “see no data in that item.” A default role (DefaultReader) is created to keep existing read access for users who had ReadAll; if you removed ReadAll and didn’t add the user to a role, they may get 403 trying to browse/open via OneLake Catalog. 
  1. SQL Analytics endpoint identity mode
  • With OneLake table/folder security enabled, the lakehouse’s SQL Analytics endpoint must be set to “User’s identity mode” (Security tab). If it’s still using a fixed/delegated identity, authorization can fail for users without workspace roles, leading to 403.

How to Fix

 

  • Verify sharing permissions on the Lakehouse

    • In Lakehouse → … → Manage permissions → Direct access, confirm the user/group has Read (not just ReadAll).
    • If you rely on ReadAll for Spark, keep Read as well; ReadAll alone doesn’t grant lakehouse data access. 

  • If OneLake security (preview) is ON, add the user to a data access role

    • Go to Lakehouse → Manage OneLake security (preview).
    • Create/choose a role and grant Read (and optionally ReadWrite if needed).
    • Add the user/group to that role and include the specific tables/folders they should access.
    • Ensure they’re not still in the DefaultReader role if you intend to restrict them; otherwise, they keep full read access. 

  • Switch the SQL Analytics endpoint to “User’s identity mode”

    • Open the SQL Analytics endpoint → Settings → Security and set User’s identity mode.
    • This is required for OneLake table/folder security scenarios to authorize the actual user, not a fixed owner identity.

Hope this fixes your problem, kindly appreciate giving a Kudos or accept as a Solution!