Issue with Onelake security RLS

Hi g3kuser 
We would like to inquire whether have you got the chance to check the solutions provided by Shai_Karmani Vinodh247 Vinodh247 Prince0011   in commiunity to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.

Thank you.

I tried it again with a new non schema lakehouse and it worked fine this time.

Note: OneLake security = Workspace access + Data role. Missing either will fail with the same error.

Add the user (or a group) to the ALLTables role and assign at least Viewer role on the workspace. If you want legacy behaviour, recreate DefaultRole, which maps ReadAll to full table access.

Hi User,

The error UnauthorizedToAccessTableFiles indicates that the user is being blocked from accessing the underlying OneLake Delta files, rather than being denied by Row-Level Security (RLS).

A few things to verify:

• Ensure that OneLake data access roles and workspace permissions are configured correctly. Sharing the Lakehouse with Read permission alone may not be sufficient if the user doesn't have the required permissions to access the underlying Delta files.

• If you're testing OneLake Security, make sure the user has been assigned to the appropriate OneLake data access role. Removing the DefaultRole can inadvertently remove the baseline permissions required to access tables.

• Verify that the security configuration has been published/saved and allow sufficient time for permission changes to propagate.

• Test with a simple table that has no RLS or additional security policies to determine whether the issue is related to OneLake permissions or the specific table.

• Check whether the behavior is the same for both schema-enabled and non-schema-enabled Lakehouses. Since you're seeing the same error in both, it points more toward a storage permission issue than a schema-specific problem.

Based on the error, it appears the request is failing before any RLS filters are evaluated, so I'd focus on validating the user's OneLake file access first.

For more information:

• OneLake security: https://learn.microsoft.com/fabric/onelake/security/get-started-security

• Lakehouse security: https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview

• OneLake access control model: https://learn.microsoft.com/fabric/onelake/security

Could you also clarify:

• How is the user accessing the Lakehouse (SQL Analytics endpoint, Notebook, REST API, or OneLake Explorer)?

• Is OneLake Security enabled at the tenant level?

• Does the user have access to any other Lakehouse tables, or does every table return UnauthorizedToAccessTableFiles?

These details will help determine whether the issue is due to OneLake role configuration, propagation, or a service-side permission issue.

Having the DefaultRole gave access to user to all tables and all data ignoring the security role created for the user. I was able to get it working with the my exact same setup + Viewer access(Workspace) on schema enabled lakehouse. But it doesn't work for non schema lakehouse. We predominantly use non schema and would get it working with it. Also Workspace viewer access is putting us off as it is giving user access to see all the items which we don't want.

Hi  g3kuser 
Thanks for the update. What you are seeing usually comes down to two things:

1. Path mismatch between schema-enabled and non-schema lakehouses
   OneLake roles resolve tables by path Tables/<schema>/<table> for schema-enabled vs. Tables/<table> for non-schema. If the non-schema role was authored the same way as the schema one, the paths don't match and access falls back to unauthorized.
   Delete the role -> create a fresh one inside the non-schema lakehouse -> pick tables from the object picker (don't type paths) -> reassign the user.
2.  Skip Workspace Viewer, share the lakehouse directly. Open the lakehouse ->Share ->tick only Read, and untick "Read all SQL endpoint data" and "Read all OneLake data" (both bypass OneLake security).This gives access to just that lakehouse, and lets your role do the filtering.
3. End-to-end sequence for non-schema: Remove DefaultRole ->fresh role in the non-schema lakehouse ->assign user ->share lakehouse (Read only) -> no workspace access -> wait for ~15 min -> user re-authenticates.

   If it still fails, raise a Microsoft Support ticket (Fabric Support) with tenant/workspace/lakehouse IDs and the role screenshot — non-schema OneLake security is still Preview and has known gaps.

   Reference links: OneLake security overview · Row-level security · Share items in Fabric

Note: Quick check was the non-schema role created fresh inside that lakehouse, or mirrored from the schema-enabled one?

Thanks,
Srikanth Cheri
Community Support Team

Hi g3kuser 
We would like to inquire whether have you got the chance to check the solutions provided by above in commiunity to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.