Volume Mounting - Auth issue with Azure AD logins?
Closed this issue · 28 comments
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: 10.0.75.1 (10.0.75.1:445) 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 //10.0.75.1/C on /c failed: Invalid argument
...so 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.
Information
- 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
- Join a Windows 10 PC to an Azure Active Directory domain
- Log into that PC using Azure Active Directory account
- Install Docker for Windows etc...
- Run the 'volume sharing test case' in the Shared Drives section of the GUI: docker run --rm -v c:/Users:/data alpine ls /data
- Enter the Azure AD credentials when prompted
- Volume doesn't get shared :-(
Workaround
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.
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?
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: 10.0.75.1 (10.0.75.1:445) 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 //10.0.75.1/C 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
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.
Ok it took some trial and error here was my fix
- create
DockerUserlocal user - grant
DockerUserfull-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
EDIT:
DockerUser will need admin permissions to create the share, but you can remove them from administrators once the share has been created
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.
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
Any more movement on this from anyone? Using a local user is not a solution for many corporate environments.
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.
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
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.
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.
Are there any updates about this issue? The problem is still present in the latest version in caso of AAD accounts
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.
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.
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.
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.
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
@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?
@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.
I'm not allowed to create a local user account due to company policies. Looking for a real solution too!
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:
This looks to be fixed with the latest docker edge release.
@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 (2.1.0.5 as of this writing) to edge (2.1.7.0) 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
Engine:
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
containerd:
Version: v1.2.10
GitCommit: b34a5c8af56e510852c35414db4c1f4fa6172339
runc:
Version: 1.0.0-rc8+dev
GitCommit: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
docker-init:
Version: 0.18.0
GitCommit: fec3683
Looks like this update is now available in stable (2.2.0.0), although some of us are having trouble with file changes on the host not showing up in container volumes (#5530)...
This is fixed with the new filesharing implementation in 2.2.0.3, so closing this ticket.
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