Forum Discussion

fatma_akyol's avatar
fatma_akyol
Frequent Visitor
7 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 permissions.

 

The user does NOT have any workspace role (Viewer/Contributor).

 

According to the official Microsoft documentation, Lakehouse data can be shared 
without granting workspace access:
https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-sharing

 

 

However, when the user tries to open the from the OneLake Catalog, 
they receive the following error:

 

"User is not authorized to perform this operation. (403)"

 

Questions:

1. Is workspace access still required to open a Lakehouse from OneLake Catalog UI, even when the Lakehouse is shared directly?

2. How can we share lakehouse without workspace-level access?

Any clarification or guidance would be appreciated.

  • 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.

11 Replies

  • Hello,

    I have faced this issue so many times but I could not find any solution except giving viewer acces in workspace. I think there is something a bug or misunderstanding. 

    Happy new year

  • 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

    • fatma_akyol's avatar
      fatma_akyol
      Frequent Visitor

      Hello deborshi_nag ,

      Thank you for your response.

      The user has Read, ReadAll, and SubscribeOneLakeEvents permissions.
      We assigned the user to a OneLake security role and granted access to specific tables within this role.
      Additionally, "User’s identity mode is enabled" on the SQL Analytics Endpoint.

      We have already applied all of the recommendations mentioned above; however, the issue still persists.

      Thank you.