The share ID returned in the share-rm command accepts permissions. Those permissions can be found by looking for the assignment against the azuread object, but in the case of assigning an RBAC to that share-rm ID, it was not functional.
The difference is the the "share" vs "fileshare" in the second to last position.
I am sure there is a reason for this... but reading the share-rm ID and applying a permission to it did not give the user access. You should explain if there are any differences in behavior between using the different ID formats.
usable share ID when assigning a permission (fileshares in the second to last position)
/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts//fileServices/default/fileshares/
what share-rm returns (shares in the second to last position)
/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts//fileServices/default/shares/
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The share ID returned in the share-rm command accepts permissions. Those permissions can be found by looking for the assignment against the azuread object, but in the case of assigning an RBAC to that share-rm ID, it was not functional.
The difference is the the "share" vs "fileshare" in the second to last position.
I am sure there is a reason for this... but reading the share-rm ID and applying a permission to it did not give the user access. You should explain if there are any differences in behavior between using the different ID formats.
usable share ID when assigning a permission (fileshares in the second to last position)
/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts//fileServices/default/fileshares/
what share-rm returns (shares in the second to last position)
/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts//fileServices/default/shares/
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.