Creating Shortcuts With Limited Access in Lakehouse Source

[andrerodrigues]

We have a service account that we want to use to create a shortcut from Lakehouse Source, located in Workspace Source, to Lakehouse Target, located in Workspace Target. The admin of Workspace Source and Lakehouse Source has restricted this service account’s access so that it can only access the dbo schema and specifically tables A, B and C within that schema. However, Lakehouse Source contains many more tables spread across different schemas.

Is it possible for the service account to access tables A, B and C from the dbo schema of the Lakehouse Source via both the Lakehouse and the SQL Endpoint, and successfully create shortcuts for those same tables into Lakehouse Target in Workspace Target? The intended behaviour is that everyone who has access to Workspace B should inherit exactly the same level of access as the service account, nothing less, in this case. Is this achievable?

I’ve already tried several approaches:

The User X is admin in the Workspace Target.

I started by not granting User X access to the Workspace Source. I created a role with User X in Manage OneLake data access (preview) to give access only to the three required tables, without enabling any of the advanced settings. I also tested with the reshare option ticked in the advanced settings under the Manage OneLake data access (preview) section of the source Lakehouse, but this did not work.

In the Manage permissions section of the same Lakehouse, I added User X without selecting any permission checkboxes. This also failed. I then tested variations where I ticked "Read all Apache Spark and subscribe to events", but the result was always the same.

I also granted the following access on the SQL endpoint:

GRANT SELECT ON dbo.dim_part TO [user_x];
GRANT SELECT ON dbo.dim_partsource TO [user_x];
GRANT SELECT ON dbo.dim_site TO [user_x];

Despite all attempts, I consistently encountered the same error when trying to create a shortcut. It’s important to note that User X is also the owner of the source Lakehouse:

{
"error": {
"code": "Forbidden",
"message": "User is not authorized to perform current operation for workspace 'Workspace Source', artifact 'Lakehouse Source'.",
"target": null,
"details": null
}
}

To work around this, I tried granting User X viewer access on the workspace, but this didn’t solve the issue either.
One relevant point: Lakehouse Schemas (Public Preview) is not enabled on the source Lakehouse, although it is enabled on the target Lakehouse. I’ve also tested with the target Lakehouse having this setting disabled, but the error still occurs.
Given all of the above, could you confirm whether it is possible to create a shortcut from a source Lakehouse with restricted table access, into a target Lakehouse, and if so, what are the correct steps to achieve this?

@Microsoft @Fabric @microsoftfabric 

[v-veshwara-msft]

Hi @andrerodrigues ,
We wanted to kindly follow up regarding your query. If you need any further assistance, please reach out.
Thank you.

[v-veshwara-msft]

Hi @andrerodrigues ,

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.

[BhaveshPatel]

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. 

[andrerodrigues]

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!

[v-veshwara-msft · Accepted solution]

Hi @andrerodrigues ,
Just wanted to check if the response provided was helpful. If further assistance is needed, please reach out.
Thank you.

[andrerodrigues]

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