Forum Discussion
Dataset level access in OneLakeSecurity
Last week, I was able to grant access to individual shortcuts using OneLake Security. However, as of today, the same functionality is not working as expected.
Currently, the fanric onelake security does not allow selecting or granting access at the dataset level. Instead, access can only be granted at the schema level.
Could you please confirm:
- If this is a known issue or recent product change
- Whether any updates or fixes have been rolled out at the product level
Hi thiyaguvr,
Hope you're doing well!
OneLake security roles grant access based on Scope, where objects can be tables, folders, or schemas. For schema-enabled items, a valid table must also be in a valid schema folder. (Microsoft Learn)
A folder is only considered a valid table if it exists in the Tables/ directory, contains a _delta_log folder with metadata JSON files, and does not contain any child shortcuts. Any tables that do not meet those criteria will have access denied if table-level security is configured on them. (GitHub)
Your issue is most likely explained by this shortcut constraint. If your datasets are backed by shortcuts, OneLake Security cannot treat them as valid tables at the individual/dataset level, which would explain why you can only select at the schema level (the parent folder), not at the individual shortcut/table level.
This is by design in the current architecture, not a bug or regression.
The workaround would be to either:
- Grant access at the schema level (as you're currently seeing)
- Or restructure so that security-sensitive tables are not shortcut-backed
Fabric/onelake/security/table-folder-security
Hope this helps! I'm curious to know your opinion after checking 🙂
Hi thiyaguvr,
Thank you for posting your query in the Microsoft Fabric Community Forum.Based on the official documentation, OneLake security applies to tables and folders within a data item, and permissions are granted only on supported OneLake objects.
For shortcuts, access depends on how the underlying data is exposed and secured, and OneLake security applies only to supported table/folder representations rather than all shortcut scenarios.
if shortcuts are no longer appearing as selectable objects, they may not currently be recognized as securable objects in the role definition, which can result in only higher-level selections (such as schema/folder) being available.
As a workaround Grant access at the table/folder (or schema) level within the Lakehouse as already mentioned by oussamahaimoud and use semantic model permissions or RLS/OLS if you need dataset-level access control.
For your reference:
Get started with OneLake security - Microsoft Fabric | Microsoft Learn
Secure and manage OneLake shortcuts - Microsoft Fabric | Microsoft Learn
Thanks, oussamahaimoud for sharing valuable insights.
Best regards,
Ganesh Singamshetty
6 Replies
Hi thiyaguvr,
Thank you for posting your query in the Microsoft Fabric Community Forum.Based on the official documentation, OneLake security applies to tables and folders within a data item, and permissions are granted only on supported OneLake objects.
For shortcuts, access depends on how the underlying data is exposed and secured, and OneLake security applies only to supported table/folder representations rather than all shortcut scenarios.
if shortcuts are no longer appearing as selectable objects, they may not currently be recognized as securable objects in the role definition, which can result in only higher-level selections (such as schema/folder) being available.
As a workaround Grant access at the table/folder (or schema) level within the Lakehouse as already mentioned by oussamahaimoud and use semantic model permissions or RLS/OLS if you need dataset-level access control.
For your reference:
Get started with OneLake security - Microsoft Fabric | Microsoft Learn
Secure and manage OneLake shortcuts - Microsoft Fabric | Microsoft Learn
Thanks, oussamahaimoud for sharing valuable insights.
Best regards,
Ganesh SingamshettyHi thiyaguvr,
Hope you're doing well!
OneLake security roles grant access based on Scope, where objects can be tables, folders, or schemas. For schema-enabled items, a valid table must also be in a valid schema folder. (Microsoft Learn)
A folder is only considered a valid table if it exists in the Tables/ directory, contains a _delta_log folder with metadata JSON files, and does not contain any child shortcuts. Any tables that do not meet those criteria will have access denied if table-level security is configured on them. (GitHub)
Your issue is most likely explained by this shortcut constraint. If your datasets are backed by shortcuts, OneLake Security cannot treat them as valid tables at the individual/dataset level, which would explain why you can only select at the schema level (the parent folder), not at the individual shortcut/table level.
This is by design in the current architecture, not a bug or regression.
The workaround would be to either:
- Grant access at the schema level (as you're currently seeing)
- Or restructure so that security-sensitive tables are not shortcut-backed
Fabric/onelake/security/table-folder-security
Hope this helps! I'm curious to know your opinion after checking 🙂
Hi oussamahaimoud ,
As I mentioned earlier, until last week I was able to create a OneLake security role and select specific shortcuts within it.
Has there been any recent change or fix that restricts assigning permissions directly on shortcuts?
Hello thiyaguvr,
We hope you're doing well. Could you please confirm whether your issue has been resolved or if you're still facing challenges? Your update will be valuable to the community and may assist others with similar concerns.
Thank you.
Hello thiyaguvr,
Hope everything’s going great with you. Just checking, the issue been resolved or are you still running into problems? Sharing an update can really help others facing the same thing.
Thank you.
