Description
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.