Sharing drives does not work for Azure AD user accounts

[jayfresh]

Hi,

I'm attempting to share my C: drive as per the instructions here - https://docs.docker.com/docker-for-windows/#/shared-drives.

However, it doesn't seem possible to use my login details in the Shared Drives username/password dialog - none of the usernames of the form AzureAD\username, or email@domain or AzureAD\email@domain get through the login.

I've tried setting up a local admin user, "admin", and I can successfully share the drive using that account, but according to the troubleshooting, https://docs.docker.com/docker-for-windows/troubleshoot/#verify-domain-user-has-permissions-for-shared-drives-volumes, you have to run the docker commands using the same user as you have used to share the drive.

The same troubleshooting mentions that the solution is to login with a domain user, which in my case I assume is the AzureAD user, but as I mentioned, Docker is not accepting the credentials.

Information

Diagnostic ID: B84C9FF9-58D6-4C1D-8BBA-D94E145DE072/2016-10-06_10-14-53

This is on Windows 10, version 1607, OS Build 14393.222.

Steps to reproduce the behavior

1. Login using Azure AD user account
2. Install Docker as normal
3. Try to share a drive using the Azure AD user account
4. Credentials popup reappears, not accepting credentials

[simonferquel]

When the popup appears, what is the value prefilled for user name ?
Can you try not to change it and give your Azure AD password ?

[jayfresh]

Hi Simon, there isn't any value prefilled for user name. And if I fill in a user name and password, the popup reappears without any value prefilled - see screenshot.

I'm using the latest stable build, v1.12.1 I think (from docker --version)

[jayfresh]

I've downloaded the beta version and it's a bit different - there is a prefilled user name, but when I put my password in, the popup disappears and the C drive checkbox goes back to being unchecked. I'm just checking the log...

[simonferquel]

Ok, we might have to setup a lab to further test AzureAD related scenarios.
I'll track the issue in our internal repo, in the mean time, having a local account with correct NTFS rights is a perfectly suitable workaround

[jayfresh]

the problem with using a local account to share the drive is that you hit the problem mentioned in the troubleshooting - you can't be logged in as your AzureAD account and run docker commands, as that's not the same user account as you used to share the C drive...

[jayfresh]

Here's the diagnostic ID running this on the beta version: B84C9FF9-58D6-4C1D-8BBA-D94E145DE072/2016-10-06_12-23-37

[jayfresh]

In the log, got the error System error 1332 has occurred. No mapping between account names and security IDs was done.

[simonferquel]

With the beta you should be able to:

• Log on with the AzureAD account
• Create a local account (without login in)
• Put correct ntfs rights for the local account
• Launch Docker For Windows from the Azure AD account session, and when sharing the drive, specifiy the local account and password

What you can't do is switch from different user account sessions and run docker commands (all docker commands must be done from the same session, but the account used for drive sharing can be different)

[jayfresh]

Thanks! Two queries though - the popup credentials won't let me change the username to use the local admin account, it just says it's an invalid login/password when I submit it. Secondly, I don't know what you mean about the correct ntfs rights for the local account, could you explain? Thanks again.

[simonferquel]

as a username just put your username without the AzureAD prefix (and make sure the account password is not expired)

The thing about NTFS rights is that you have to make sure the local user has the rights to read and/or write in the folder you want to mount as a volume in a container

[jayfresh]

OK, that works! Great, thanks for the support. I'll look out for updates where it stops being necessary to use a local admin account

[jayfresh]

Sadly, I spoke too soon. Whilst I can run a command like docker run --rm -v c:/Users:/data <image> ls /data, I can't run a command like docker run --rm -v c:/Users/<Azure account>:/data <image> ls /data - I get a Permission denied error. However, I can run docker run --rm -v c:/Users/<admin account>:/data <image> ls /data.

I verified I can't access other account folders in c:/Users. I've checked the folder permissions for the Azure account folder and it says that the Administrators group has full control, so I don't understand why docker can't access the folder.

[simonferquel]

Try to add read access directly to your local user on the folder you want to mount. I think that for security reasons, rights on the administrators group are ignored if you are not in an elevated context (which is not possible remotely)

[rn]

Closing this issue due to inactivity. Please re-open if the suggested solution does not work or if there is another update.

[jayfresh]

Sorry, yes I can confirm adding admin rights to the folder you want to mount, and authenticating as the admin user account in Docker works. Thanks!

[uday31in]

This issue is back again - docker for windows version up to date.

Diagnostic ID: 06C36E21-8FEF-43AA-86E2-79C81B2558BE/2017-07-05_14-42-09

After clicking on C drive it asks for credential but nothing happens. Check box gets unchecked automatically.

[dsschnau]

I'm experiencing the same issue as @uday31in . My log id is E87073EA-E0FA-422F-8846-291E2006D435/2017-07-24_15-59-00

I can share the drive with a non-AzureAD admin account on my pc, but then I am unable to do work with Docker running as my AzureAD account.

[dopry]

I can confirm I am seeing the same behavior with my AzureAD account.
When I share a drive I provide my credentials, but the box goes back to being unchecked after providing correct credentials.

[murdockcrc]

I can confirm the issue on Docker for Windows 17.09.0-ce, build afdb6d4

[michaelsrichter]

any update on this?

[techbunny]

I had a similar experience with Docker for Windows 17.09.0-ce-win33 (13620) Stable - 8c56a3b. My local admin account is using the format of DOMAIN\username, but the machine is not traditionally domain joined, that account is reflected in Azure AD. The Shared Drive checkbox just clears after entering the credentials. I switched to using a non-admin account that is also on my computer, which happens to be a MSA account (in email format) and that worked fine.

[Franklin89]

Have the same issue. Using a company laptop that is being authenticated by AzureAD.
What is the best solution to get Docker up and running shared folders?

[sarvasana]

17.09.1-ce-win42 (14687) same issue

[pmundt]

This is still an issue, and should certainly be re-opened - rather, it should never have been closed in the first place, as only a workaround was identified and the root cause (Docker's inability to handle AzureAD permissions) was never addressed.

[oofpez]

Why is this issue closed?

[KieranDevvs]

Reopen this. Even the proposed work around does not work.

[kieseld]

This needs to be reopened. Creating another non AzureAD user on every one of my developers machines and going through the hoops to create the right file shares is not a solution.

[seangwright]

I posted what I found to be the simplest workaround on the other issue that is still open for anyone that can't wait for this to be fixed.

[cowwoc]

I've read suggestions above that the local user should have the same name as the AzureAD account. While this initially worked for me, I ran into problems later on: error while creating mount source path '/host_mnt/c/Users/MyUser/Documents': mkdir /host_mnt/c/Users/MyUser/Documents: permission denied.

At this point, you are supposed to grant the local user access to this directory, but the Security Properties UI was not able to grant different permissions to users with the same name even though they belong to different domains.

Here's what worked for me:

1. Follow the directions at Sharing drives does not work for Azure AD user accounts #132 (comment), making sure to give the local user a different name than the AzureAD user.
2. Try running the docker command that was previously failing.
3. If you get mkdir /host_mnt/c/Users/MyUser/Documents: permission denied go into Documents' security properties and grant the local user access.
4. If you get errors claiming that a path does not exist when it actually does (e.g. C:/Program Files/Git/data: No such file or directory or Mount denied: The source path "C:/Users/MyUser/Documents;C" doesn't exist and is not known to Docker) prefix Windows paths with an extra slash per Mount volume doesn't work on Windows 10 using git-bash docker-archive/toolbox#673 (comment). For example, /c/Users/SomeGal should be referenced as //c/Users/SomeGal.
5. Repeat steps 2 and 4 until all mounting are resolved.

[jonathanpmast]

This issue is of particular impact when the user is trying to debug an application using Visual Studio. The F5 debug experience in VS will attempt to mount various folders deep in the User/AppData folder which a local docker account will not be able to access. Or at least seems to be unable to access. The particular path that got me here was: /c/Users/<aad_user_folder>/AppData/Roaming/ASP.NET/Https

[mattcowen]

@rn could you reopen this please?

[cdituri]

seconding @mattcowen - hitting this issue as we speak. Can we re-open?

[gingters]

@rn @mattcowen Please re-open. This is blocking us completely, as domain policies do not allow the creation of local user accounts and thus making the workaround and with that docker usage absolutely impossible.

[stephen-turner]

This is not fixable with our current file sharing solution, which is built on Samba. The restriction is in Samba, not in Docker Desktop, so we (Docker) can't do anything about it.

Having said that, we are looking at moving away from Samba, in which case this would no longer be an issue.

[pchakravarthy]

@stephen-turner Is there any other reasonable workaround rather than creating a local user for this issue? This issue is hurting us bad!

[ilmax]

@stephen-turner is there an open issue to track moving away from Samba? I think this is a show stopper for a lot of people so it would be nice to have an issue to up-vote in order to prioritize it based on customer needs

[stephen-turner]

Don't worry, we are fully aware of the need.

[aliiqbalIntelligenes]

@stephen-turner Any update on this issue?

[stephen-turner]

In fact, yes. The replacement has already been released on the Edge channel so you can test it now.

[aliiqbalIntelligenes]

@stephen-turner OK Thanks for the quick response.

[out-of-band]

I switched to the Edge channel (separate issue but I had to download Edge independently; switching to Edge from within the Docker Desktop client no longer works correctly, it just restarts in Stable), and I'm still unable to share drives with an Azure AD account.

On Docker 2.1.6.1 (40900), attempting to share C: results in a never-ending loop of the credentials dialog. If I type in incorrect credentials, I get an error. If I type in correct credentials, the dialog just reappears. Logs seem to indicate that Samba is still being used.

[16:52:29.198][APIRequestLogger  ][Info   ] [36c27275] <LifecycleClient start> POST http://localhost/mount
[16:52:29.215][APIRequestLogger  ][Info   ] [36c27275] <LifecycleClient end> POST http://localhost/mount -> 500 InternalServerError (took 16ms)
[16:52:29.216][SambaShare        ][Error  ] Unable to mount C drive: unexpected error: System.AggregateException: One or more errors occurred. ---> Docker.Backend.HttpBadResponseException: Exception of type 'Docker.Backend.HttpBadResponseException' was thrown.

[stephen-turner]

Thanks, @out-of-band. We think we know why this is: there's a race condition at startup that means it occasionally gets into the wrong filesharing mode. There will be another Edge release next week fixing this.

[datocrats-org]

This workaround had been working for me for 104 days, just stopped working. I do not think it's a password expiry issue on my same-name non AzureAD account. I tried using Windows Properties to set full control for my UserName account and AzureAD\UserName account. The only changes I made to my config recently was to remove some old Docker images and to update docker-compose and docker-ce within my ubuntu 18 WSL Windows Subsystem for Linux (which I think uses Docker Desktop as its daemon natively over tcp://localhost:2375 per this tutorial. I am using Docker Desktop Community v 2.1.0.1 (37199) stable. I like the ability to control the containers started from within WSL running vscode remotely from within vscode in Windows, and to be able to use the networks interchangeably. I am thinking now it is a better approach to run all Docker including Hub from within the Ubuntu WSL.

[stephen-turner]

@datocrats-org Please try the new Edge release. As explained above, we are not using Samba any more.

[stephen-turner]

And @out-of-band, your bug should be fixed in the latest Edge release.

[out-of-band]

Yep thanks @stephen-turner. I've been on the new Edge release since about 15 minutes after it was published and it's working great for me. Thank you!

[dlineg4]

The latest Edge release also worked for me!

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked