Azure-docs: Long delays in assigning Share permission

[RonPattersonBadger]

Section 2 describes creating the Share permission. It has been my experience that it can take several hours before the share permission change is affected on the file share, resulting (during the interim) in vexing errors mapping the drive. Tools like PowerShell's "Get-SMBShareAccess" also don't work to show the Share's configuration, so it seems to be impossible to detect when the share permission has been added (and validate your work). At a minimum, a warning in the documentation that it can take a long time for the Role assignment to result in a Share permission should be added. Ideally, there should be a mechanism to know when the Share permission has been added.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: fba964be-3f77-d80c-f1a5-35bb1430bb8f
• Version Independent ID: fe70b11e-10fe-5a8c-1fad-b22a83693503
• Content: Enable Active Directory authentication over SMB for Azure Files
• Content Source: articles/storage/files/storage-files-identity-auth-active-directory-enable.md
• Service: storage
• Sub-service: files
• GitHub Login: @roygara
• Microsoft Alias: rogarana

[TravisCragg-MSFT]

@RonPattersonBadger Thanks for the feedback. We are actively investigating and will get back to you soon.

[Kenks84]

Thanks for this comment, I've been pulling my hair out, but might just leave it until tomorrow to see if I can access it using AD Credentials

How long have you been waiting

[ziesemer]

Agreed, this is agonizingly slow. Past an hour already, will see how many hours this turns into...

[RonPattersonBadger]

I have waited upwards of 5 hours. So you need to be patient. I have to wonder if there is some process that kicks off "on a schedule" to deal with these requests. Like you see with Exchange and it's treatment of retention policy.

[SumanthMarigowda-MSFT]

@RonPattersonBadger Apologies for delay in responding here!
Are you still finding any difficulties, what is the error are you getting while providing the access?

It dependents on owner what share-level permissions can be provided/given to the users:

Storage File Data SMB Share Reader allows read access in Azure Storage file shares over SMB.
Storage File Data SMB Share Contributor allows read, write, and delete access in Azure Storage file shares over SMB.
Storage File Data SMB Share Elevated Contributor allows read, write, delete and modify NTFS permissions in Azure Storage file shares over SMB.

I'd recommend posting your question in https://social.msdn.microsoft.com/forums/azure/en-US/home?forum=windowsazuredata since it's not directly related to the documentation. We'll follow up there. We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

[ziesemer]

@SumanthMarigowda-MSFT - Please consider re-opening this, even just for this reason:

At a minimum, a warning in the documentation that it can take a long time for the Role assignment to result in a Share permission should be added.

This is directly related to the documentation.

Please specify what the expected time frame is for permissions to take effect, e.g. "within 2 hours", or that "an update job runs every 6 hours", or whatever the case may be. Then this can be used as guidance as to if / when support tickets should be opened for this, etc.

[RonPattersonBadger]

ziesemer is right. The issue is directly related to the documentation. There is no 'error' as such (just that you can't map to the drive until the share permission is populated). This is not a question of understanding the roles, it is a question of a Microsoft process taking place that is not documented.