Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!View all the Fabric Data Days sessions on demand. View schedule
Hi folks,
I'm trying to work out the minimum permissions I need to grant a user to be able to view a schema (and its tables) in a OneLake lakehouse. Specifically I'm looking at OLS in the lakehouse and not in the SQL Endpoint (which does work but IIRC forces queries to use Direct Query).
Can you see where I might be going wrong, please?
I have a lakehouse with 3 schemas in it (dbo, schema1, schema2) and a test USER
Steps I've taken
What we're seeing is that;
I've used the following as reference documents;
Lakehouse sharing and permission management - Microsoft Fabric | Microsoft Learn
Share items in Microsoft Fabric - Microsoft Fabric | Microsoft Learn
Solved! Go to Solution.
I've discovered the practical 'minimum permissions' to grant access to a table - this forms the practical solution as things currently stand.
If there is a more minimal permission set that works, I'd like to know - there appears to be no explicit 'Explore' permission. 😞
These first 4 steps grant access to the table for pyspark.
This step grants access to preview the data
The user is now able to see report data based on the Direct Lake model.
Hi @spencer_sa ,
Thank you for your detailed summary and for taking the time to explore the current permission model in Microsoft Fabric.
You're correct, there is currently no explicit "Explore" permission in Microsoft Fabric. The combination you've identified Lakehouse-level Read access, schema/table access via OneLake Data Access roles, and GRANT SELECT on the SQL Endpoint forms the practical minimum permission set to enable PySpark querying, table preview in the UI, and Direct Lake semantic model access.
This hybrid approach is expected behavior under the current security model. We appreciate your findings, and your feedback is valuable as we work toward simplifying and unifying permission management in future updates.
If this post helps, then please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster.
Thank you.
Hi @spencer_sa ,
Thank you for posting in the Microsoft Fabric Community.
The issue is due to missing Explore permissions, which are required for table preview in the Fabric UI. Since the USER has no workspace role, implicit permissions are missing.
To fix this, grant Read + Explore on the Lakehouse and ensure Read access is assigned at both the schema and table levels. Verify that "Manage OneLake Data Access (Preview)" is fully applied and check for any Object-Level Security (OLS) restrictions.
If the issue persists, assign Storage Blob Data Reader in Azure to allow OneLake access. As an alternative, assigning the Viewer role in the workspace can resolve this, but you would need to separately restrict SQL Endpoint access if required.
For more details, refer to the official Microsoft documentation on Lakehouse sharing and permission management - Microsoft Fabric | Microsoft Learn which explains how to manage Lakehouse permissions effectively.
I hope my suggestions give you good idea, if you need any further assistance, feel free to reach out.
If this post helps, then please give us Kudos and consider Accept it as a solution to help the other members find it more quickly.
Thank you.
No Explore permissions regardless of removing and re-adding.
I played with a lot of things and ended up GRANTing SELECT on the schema in the SQL Endpoint which caused both the Preview to work *and* the semantic model/report to be able to see the data.
I'm also guessing over the next few months this whole security model is going to be revamped in light of Arun's announcement.
Helo @spencer_sa ,
Thank you for the update! I completely understand your frustration with the Explore permissions not working as expected. It’s great that granting SELECT permissions on the SQL Endpoint helped solve the issue and allowed both the Preview and the semantic model/report to work properly.
As you mentioned, there may be some changes to the security model in the future based on Arun’s announcement. These changes might help improve how permissions are handled.
For now, if the SELECT permission on the SQL Endpoint is working well for you, it seems like a good solution.
If this post helps, then please give us Kudos and consider Accept it as a solution to help the other members find it more quickly.
Thank you.
Hi @spencer_sa ,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. If my response has addressed your query, please accept it as a solution and give a 'Kudos' so other members can easily find it.
Thank you.
I've discovered the practical 'minimum permissions' to grant access to a table - this forms the practical solution as things currently stand.
If there is a more minimal permission set that works, I'd like to know - there appears to be no explicit 'Explore' permission. 😞
These first 4 steps grant access to the table for pyspark.
This step grants access to preview the data
The user is now able to see report data based on the Direct Lake model.
Hi @spencer_sa ,
Thank you for your detailed summary and for taking the time to explore the current permission model in Microsoft Fabric.
You're correct, there is currently no explicit "Explore" permission in Microsoft Fabric. The combination you've identified Lakehouse-level Read access, schema/table access via OneLake Data Access roles, and GRANT SELECT on the SQL Endpoint forms the practical minimum permission set to enable PySpark querying, table preview in the UI, and Direct Lake semantic model access.
This hybrid approach is expected behavior under the current security model. We appreciate your findings, and your feedback is valuable as we work toward simplifying and unifying permission management in future updates.
If this post helps, then please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster.
Thank you.
How does one explicitly assign Explore permissions? The document you shared (which is also the one I've been using as reference material) doesn't cover that - just ReadAll and SubscribeOneLakeEvents.
"Manage OneLake Data Access (Preview)" is definitely fully applied as far as it goes (the UI has changed over the weekend 🙂 ) I have a single role and a single USER in that role, and the schema and tables have been added to the role. These are the only OLS restrictions (I created this lakehouse/files specifically for this test)
I can also access the data using pyspark - it's just the Preview (and also an attached semantic model, but that's out of scope) that have the issues. I'm beginning to think I need to add SQL Endpoint OLS - bleh.
Hello @spencer_sa ,
Thank you for your follow-up question, and I appreciate your patience. In Microsoft Fabric, the Explore permission is not explicitly assigned but is implicitly granted when a user has Read access at the Lakehouse level and Manage OneLake Data Access (Preview) enabled.
Since the user can query data via PySpark but is unable to preview tables in the UI, the issue is likely due to missing Lakehouse-level Read + Explore permissions rather than schema-level access.
To resolve this, I recommend navigating to Lakehouse > Settings > Permissions and ensuring that the user has Read + Explore permissions on the entire Lakehouse, not just on specific schemas or tables. If you do not see the Explore option, you can try removing and re-adding Read access, as Explore is typically included implicitly. Additionally, SQL Endpoint OLS is not required for table preview in the UI, as it only affects SQL-based queries.
If this post helps, then please give us Kudos and consider Accept it as a solution to help the other members find it more quickly.
Thank you.
Does the user have any role in the workspace?
No. No workspace role. Just sharing of lakehouse item and then permissions on schemas inside the lakehouse.
If I make USER a viewer, then I'd have to lock down the SQL Endpoint separately.