Forum Discussion
Creating Shortcuts With Limited Access in Lakehouse Source
Hi Anonymous ,
Just wanted to check if the response provided was helpful. If further assistance is needed, please reach out.
Thank you.
Hi Anonymous ,
Thanks for the detailed explanation and for outlining the steps you've already tried.
Based on how shortcut creation works in Fabric, the issue you're seeing might be due to the following:
To create a shortcut, the service account must have write permission on the Lakehouse where the shortcut is being created (in this case, Lakehouse Target in Workspace Target), and ReadAll permission on the source Lakehouse at the artifact level. Having access only to specific schemas or a limited set of tables in the source Lakehouse is not sufficient. The shortcut operation requires access to the full metadata of the source Lakehouse, which is only available when the account has artifact-level permissions.
Please visit the below link for more details:
Secure and manage OneLake shortcuts - Microsoft Fabric | Microsoft Learn
Additionally, in the Tables folder, you can only create shortcuts at the top level. Shortcuts aren't supported in subfolders of the Tables folder.
Unify data sources with OneLake shortcuts - Microsoft Fabric | Microsoft Learn
Users in the Admin, Member, and Contributor roles have full access to read data from a shortcut, even if OneLake data access roles are in place. But they still need proper access on both the shortcut location and the source Lakehouse, as defined by the workspace roles.
Users in the Viewer role, or those who had a Lakehouse shared with them directly, have access limited based on whether they’re included in a OneLake data access role.
Secure and manage OneLake shortcuts - Microsoft Fabric | Microsoft Learn
Hope this helps. Please reach out for further assistance.
Thank you.
Minimum Data Security is Read only in Fabric Lakehouse or Fabric Warehouse ( Admin, Member, Contributor or Viewer Role). Direct Lake has row level security in Power BI Semantic Model. This is reason why they call it Unified Data Architecture.
Hi all,
Thanks for the input so far.
Just to clarify a couple of points:
Requiring ReadAll on the source Lakehouse defeats the purpose of restricting access to specific tables. It grants visibility into all metadata and objects, which goes against the goal of least-privilege access.
Regarding shortcut placement: I believe there was a misunderstanding. I wasn’t referring to creating a shortcut in a subfolder under Files, but rather within a schema (e.g. dbo) in the Tables section. Schemas and subfolders are not the same, schemas are logical groupings within Tables, supported in preview. So the “must be at the top level of Tables” statement likely stems from confusing these two.
If shortcuts can’t support scoped access or respect schema-level targeting, I’ll consider alternative items like data pipelines or copy jobs
Thanks again!