Issues with OneLake Data Access in Lakehouse: Folder & Table-Level Restrictions Not Working

[FabricTrailLear]

Hi,

I’m facing an issue with OneLake data access in Lakehouse. For example:

• I assigned the Viewer role at the Lakehouse level to a user and created roles in OneLake data access with permissions set at both file and folder levels. Despite this, the user was still able to access all folders and tables.

• Then, I also gave the user Viewer access at the workspace level and repeated the process—creating roles and restricting access to certain folders and tables. However, the user was still able to see all tables and folders.

This behavior doesn’t match Microsoft’s documentation (https://learn.microsoft.com/en-us/fabric/onelake/security/data-access-control-model ).

Additionally, I want to understand how to implement more granular access control in Lakehouse, such as:

• Allowing certain users to view or edit only specific schemas or tables while restricting access to others.

• Restricting delete permissions on tables for some users, while allowing others to delete.

How can these fine-grained controls be achieved within a Lakehouse environment? Are there specific role or permission settings for schema/table-level access and action restrictions like delete?

Any insights or examples on managing these permissions would be really helpful.

Thanks in advance!

[burakkaragoz · Accepted solution]

Hi @FabricTrailLear ,

You're right to expect more granular control. The current OneLake data access model in Lakehouse still has some limitations when it comes to enforcing folder- and table-level restrictions, especially when using Viewer or custom roles.

Here are a few things to double-check:

1. Role propagation: Even if you assign roles at the folder or table level, if the user has broader access at the Lakehouse level (like Viewer), that can override the lower-level restrictions. Try removing the Lakehouse-level role and only assigning access at the specific folder or table level.

2. Schema-level permissions: As of now, schema-level restrictions are not fully enforced in all scenarios. If you're using Direct Lake or shortcuts, users might still see metadata even if they can't query the data.

3. Workspace role inheritance: If the user is a Member or Contributor in the workspace, they’ll bypass most OneLake-level restrictions. Make sure they’re only assigned roles through OneLake access control, not workspace roles.

4. Preview limitations: Some of the fine-grained access controls are still evolving. If you're testing this in a trial or preview environment, behavior might not fully align with the documentation yet.

If you need strict isolation, one workaround is to split sensitive data into separate Lakehouses and manage access at the workspace level.

If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.

[FabricTrailLear]

Hi @burakkaragoz ,

Thanks for the detailed explanation!

I tested removing the user’s Viewer role at the Lakehouse level and assigned permissions only at specific folder and table levels via OneLake data access. However, after removing the Lakehouse-level role, the user no longer sees the Lakehouse in the OneLake catalog (where shared Fabric items appear), effectively losing all access.

So it seems that removing broader access also removes visibility, making it difficult to enforce granular folder/table restrictions without losing access.

Also, if schema-level or table-level restrictions are still evolving, is there a timeline or roadmap to expect more granular access controls soon?

Appreciate your help!