Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Volume Mounting - Auth issue with Azure AD logins? #1352

piers7 opened this issue Nov 22, 2017 · 28 comments

Volume Mounting - Auth issue with Azure AD logins? #1352

piers7 opened this issue Nov 22, 2017 · 28 comments


Copy link

@piers7 piers7 commented Nov 22, 2017

Expected behavior

Given a user logs in using Azure Active Directory credentials to a AAD-joined Windows 10 machine
and provides those credentials to Docker for Shared Drives sharing
then containers should be able to share volumes from the host

Actual behavior

Sharing the volume fails silently in the tasktray GUI, and with 'Error response from daemon: An error occured while sharing drive' from powershell. Log files (below) seem to indicate a failure in the VM to connect.
Note that volume sharing via a local user seems to work fine.

The sequence of events in the log file appears to indicate that the share was initially created successfully:

[22:02:44.287][CredentialAsker][Info   ] Storing credentials: AzureAD\PiersWilliams:***********
[22:02:44.314][NamedPipeClient][Info   ] Sending Version()...
[22:02:44.315][NamedPipeClient][Info   ] Received response for Version
[22:02:44.315][NamedPipeClient][Info   ] Sending Mount(C, AzureAD\PiersWilliams:**********, Docker.Core.Settings)...
[22:02:44.315][NamedPipeServer][Info   ] Version()
[22:02:44.315][NamedPipeServer][Info   ] Version done in 00:00:00.
[22:02:44.316][NamedPipeServer][Info   ] Mount(C, AzureAD\PiersWilliams:**********, Docker.Core.Settings)
[22:02:44.364][SambaShare     ][Info   ] Mount C
[22:02:44.397][Cmd            ][Info   ] This shared resource does not exist.
[22:02:44.397][Cmd            ][Info   ] More help is available by typing NET HELPMSG 2310.
[22:02:44.400][SambaShare     ][Info   ] "C" is not shared
[22:02:44.400][SambaShare     ][Info   ] Creating share "C:\" as "C" with Full Control to "AzureAD\PiersWilliams"
[22:02:44.462][Cmd            ][Info   ] C was shared successfully.

... but apparently then there is a problem mounting the share in the VM...

[22:02:45.774][ApiProxy       ][Info   ] proxy << POST /v1.32/containers/dc62883411e23e8ec08bb33fae1adfbb58f32335c011e53f3b7a90b5b6a55e47/wait?condition=removed
[22:02:45.779][SambaShare     ][Error  ] Unable to mount C drive: ( open
umount: can't unmount /c: Invalid argument
umount: can't unmount /C: Invalid argument
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting // on /c failed: Invalid argument the share is torn down, and then recreated (?!) and this time the create fails (note: the username used now seems to be missing the domain prefix):

[22:02:45.779][SambaShare     ][Info   ] Removing share C
[22:02:45.858][SambaShare     ][Info   ] Mount C
[22:02:45.882][Cmd            ][Info   ] This shared resource does not exist.
[22:02:45.882][Cmd            ][Info   ] More help is available by typing NET HELPMSG 2310.
[22:02:45.884][SambaShare     ][Info   ] "C" is not shared
[22:02:45.884][SambaShare     ][Info   ] Creating share "C:\" as "C" with Full Control to "PiersWilliams"
[22:02:45.913][Cmd            ][Info   ] System error 1332 has occurred.
[22:02:45.913][Cmd            ][Info   ] No mapping between account names and security IDs was done.


  • Diagnostic ID: 52997EA1-161C-41B0-AB27-9BD951A90D89/2017-11-22_21-48-18
  • Docker Community Edition Version 17.09.0-ce-win33 (13620), Channel: stable, 8c56a3bhost on Windows 10 Professional

Full log attached: log.txt

Steps to reproduce the behavior

  1. Join a Windows 10 PC to an Azure Active Directory domain
  2. Log into that PC using Azure Active Directory account
  3. Install Docker for Windows etc...
  4. Run the 'volume sharing test case' in the Shared Drives section of the GUI: docker run --rm -v c:/Users:/data alpine ls /data
  5. Enter the Azure AD credentials when prompted
  6. Volume doesn't get shared :-(


As a number of commentators below have noted, a 'workaround' is to create a local user with the same name and password as your AAD user, and give them local admin. This works for as long as the passwords stay in-sync, and provided you don't have a restriction on doing so in the first place (which wouldn't be uncommon in an organisation using AAD, methinks). The manual overhead would also likely be seen as problematic across a large fleet.

Copy link

@joshua-barnett joshua-barnett commented Jan 25, 2018

This seems like quite an important issue, many companies use AzureAD to manage their user credentials including their developers (unfortunately).

Has anyone found a workaround for this issue or diagnosed the cause of this issue?

Copy link

@tonymet tonymet commented Feb 14, 2018

I have the same issue here is my diagnostic 19F0A27A-5C99-493C-9E97-8550072F75BB/2018-02-13_22-04-08

 ] [  941.693280] docker0: port 1(vethddd50e4) entered disabled state
[21:46:17.682][ApiProxy       ][Info   ] time="2018-02-13T21:46:17-08:00" msg="proxy << POST /v1.35/containers/xxx/wait?condition=removed\n"
[21:46:17.690][SambaShare     ][Error  ] Unable to mount C drive: ( open
rm: '/c' is a directory
rm: can't remove '/C': No such file or directory
umount: can't unmount /host_mnt/c: Invalid argument
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting // on /host_mnt/c failed: Invalid argument

[21:46:17.690][SambaShare     ][Info   ] Removing share C
[21:46:17.874][SambaShare     ][Info   ] Mount C
[21:46:17.925][Cmd            ][Info   ] This shared resource does not exist.
[21:46:17.925][Cmd            ][Info   ] More help is available by typing NET HELPMSG 2310.
[21:46:17.932][SambaShare     ][Info   ] "C" is not shared

Copy link

@tonymet tonymet commented Feb 14, 2018

Here are the workarounds I tried

  • authenticated the share using "DockerUser" . In this case DockerUser (an administrator) cannot see files when the volume is mounted.
  • creating the share manually. In this case docker un-registers the share.

Copy link

@tonymet tonymet commented Feb 15, 2018

Ok it took some trial and error here was my fix

  • create DockerUser local user
  • grant DockerUser full-control on the directory containing the dirs that you want to use as docker volumes (e.g. %HOME%/projects/)
  • now you should be able to do this in the powershell to list the contents
 docker run --rm -v c:/Users:/data alpine ls /data/USERNAME/projects

DockerUser will need admin permissions to create the share, but you can remove them from administrators once the share has been created

Copy link

@sergedomk sergedomk commented Jul 6, 2018

Unfortunately, creating a local user as a workaround won't work for me. It bypasses company security policy.

I'll need an actual fix or a workaround which does not involve adding a local account.

Copy link

@katringoogoo katringoogoo commented Aug 14, 2018

whats the best workaround for this atm? i just got the same problem in win10 after running upgrades on a machine i don't use that often. It now has the latest win 10 updates and the latest docker version (via builtin update mechanism): Version 18.06.0-ce-win72 (19098), stable channel

Copy link

@alecwhittington alecwhittington commented Sep 28, 2018

Any more movement on this from anyone? Using a local user is not a solution for many corporate environments.

Copy link

@CJKay CJKay commented Nov 19, 2018

Doesn't even appear to work locally for me... new user has full control over my development directories but permission is still denied.

This really needs a permanent fix, guys - Docker for Windows is barely usable right now for anyone using Azure AD, and not everybody can implement the necessary workarounds.

Copy link

@drcrallen drcrallen commented Dec 30, 2018

Related: #132

Copy link

@seangwright seangwright commented Mar 29, 2019

The instructions posted here #132 (comment) provide a decent workaround (definitely not a solution).

One key piece missing from those instructions is to use the exact same username (and maybe password?) as your Azure AD account.

So if your AD account is "AzureAD\UserABC" then the new local user you create should be "UserABC". When I did this I also used the same password as I have for my Azure AD account.

When looking under C:\Users I don't see a new folder and I believe Windows has linked the two accounts somehow.

Now when I check the box to share the C: drive in the Docker for Windows dialog it doesn't uncheck (I also wasn't prompted for a password - though I had previously tried with my AD username / password).

Running docker run -d --name devtest -p 8088:80 -v c:/dev:/usr/share/nginx/html nginx:latest in Powershell gets the c:\dev\index.html to be returned from nginx without any special permission settings on c:\dev

Copy link

@Maxel-S Maxel-S commented Apr 2, 2019

I have been attempting to follow this aws guide for local development which uses docker. I also am using Azure AD to log in, and it is causing permissions problems.

I was able to follow seangwright's instructions to allow sharing of my C drive by creating a local admin with the same name. However, this use case of docker seems to require more privileges which are not allowed with the Azure AD account. I validated this is the case by successfully running the test on another laptop which uses a local admin account.

I went so far as to create a local admin on this laptop I currently am logged on with Azure AD, but was not successful in running the example.

Copy link

@kieseld kieseld commented Apr 15, 2019

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. This needs to be addressed.

Copy link

@liguori liguori commented May 10, 2019

Are there any updates about this issue? The problem is still present in the latest version in caso of AAD accounts

Copy link

@rikkigouda rikkigouda commented May 12, 2019

Same problem here as of last week - any update?

I've tried a local DockerAdmin account to use when prompted, after running the command line (--rm). Have tried different local folders to ensure the account has full permission to share that folder.

Copy link

@jurby jurby commented May 28, 2019

Working workaround -

Copy link

@gingters gingters commented Jun 7, 2019

We need a real solution for this, as domain policies forbid the creation of a local user account.
This should be considered as a completely blocking issue and fixed asap, as this indeed is completely blocking us from working with docker.

Copy link

@zewpo zewpo commented Jul 11, 2019

this really sux. and it's broken a lot more than docker too. MS have also broken the ability for hyper-v
linux images to mount.cifs to access windows shares with an MS account. I strongly suspect this is the same root cause of the issue.

Copy link

@chmielot chmielot commented Jul 11, 2019

I assume that all of these issues will be solved at once when Docker for Windows will leverage WSL2. I highly doubt they’re going to fix this for Hyper-V. So we need to be patient for a few more months for the official release.

One of the major issues users have today with Docker Desktop – especially in an enterprise environment – is the reliability of Windows file bind mounts. The current implementation relies on Samba Windows service, which may be deactivated, blocked by enterprise GPOs, blocked by 3rd party firewalls etc. Docker Desktop with WSL 2 will solve this whole category of issues by leveraging WSL features for implementing bind mounts of Windows files. It will provide an “it just works” experience, out of the box.

Copy link

@ariddlestone ariddlestone commented Sep 23, 2019

The local user workaround was working for me until this morning, now that has stopped working too. Waiting a few months isn't an option - I have work to do this morning.
I think I'll have to look at a solution involving WSL1, Vagrant, or a direct virtual machine, i.e. not using Docker to manage my development environment. 🙁

I've been trying to get the rest of my team to adopt Docker - this is going to kill that effort.

Update: Using the same username as my AzureAD account allows Docker to access the drive, but not my files - still no good

Copy link

@gmattcrowley gmattcrowley commented Nov 8, 2019

@ariddlestone I also used the local user workaround, but while the directories are mounting, none of the files are visible. Any additional help to solve this?

Copy link

@ariddlestone ariddlestone commented Nov 10, 2019

@gmattcrowley I eventually solved it by having my projects in a separate folder on the c: drive, not in my users folder, and making a local user with my name and password.

Copy link

@Jobu Jobu commented Nov 11, 2019

I'm not allowed to create a local user account due to company policies. Looking for a real solution too!

Copy link

@mattbell87 mattbell87 commented Dec 11, 2019

Whoa this issue has been open for over 2 years. We use AzureAD in my team and this issue seriously limits using Docker for development. It's really hard working without volume mounting.

Here's a question: Would anyone from Microsoft be willing to help fix this?

Here's an animated gif to visualize this:


Copy link

@mattbell87 mattbell87 commented Dec 12, 2019

This looks to be fixed with the latest docker edge release.


Copy link

@alexeldeib alexeldeib commented Jan 17, 2020

@mattbell87 wow, thank you so much for pointing this out! I've battled this issue for at least a year without resolution. Confirmed I am able to use a corporate Azure AD account and share local volumes with the latest edge build.

Upgrading from stable ( as of this writing) to edge ( did the trick. Here is my version info for anyone interested:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea
 Built:             Wed Nov 13 07:22:37 2019
 OS/Arch:           windows/amd64
 Experimental:      true

Server: Docker Engine - Community
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea
  Built:            Wed Nov 13 07:29:19 2019
  OS/Arch:          linux/amd64
  Experimental:     true
  Version:          v1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
  Version:          0.18.0
  GitCommit:        fec3683

Copy link

@ariddlestone ariddlestone commented Jan 22, 2020

Looks like this update is now available in stable (, although some of us are having trouble with file changes on the host not showing up in container volumes (#5530)...

Copy link

@stephen-turner stephen-turner commented Feb 11, 2020

This is fixed with the new filesharing implementation in, so closing this ticket.

Copy link

@docker-desktop-robot docker-desktop-robot commented Jun 25, 2020

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

@docker docker locked and limited conversation to collaborators Jun 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests