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.

Sign up for GitHub

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

Jump to bottom

volume mapping would fail when hostPath is a symbolic link to a drive and containerPath is a dir path on Windows #34729

Closed
andyzhangx opened this issue Sep 5, 2017 · 6 comments
Closed

volume mapping would fail when hostPath is a symbolic link to a drive and containerPath is a dir path on Windows #34729

andyzhangx opened this issue Sep 5, 2017 · 6 comments
Labels
platform/windows version/17.03

Comments

@andyzhangx
Copy link

andyzhangx commented Sep 5, 2017 •
edited

Description
Under docker on Windows(2016 or RS3 image) env, when HostPath is a symbolic link to a drive, ContainerPath could only be a driver letter(e.g. F:), while if it's a dir path(e.g. c:\mnt), the volume mapping will fail.
Below volume mapping would fail:
docker run -d -v C:\symlink:c:\mnt --name iis microsoft/iis

While below volume mapping would succeed:
docker run -d -v C:\symlink:e: --name iis microsoft/iis

Steps to reproduce the issue:

  1. On a Windows 2016 Data center host, run below command lines:
mklink /D C:\symlink D:  (admin mode)
docker run -d -v C:\symlink:c:\mnt --name aspnet microsoft/aspnet:4.7.1-windowsservercore-1709
docker exec -it aspnet cmd
  1. In the iis container, run below command line:
    cd c:\mnt

Describe the results you received:

C:\>dir
 Volume in drive C has no label.
 Volume Serial Number is F878-8D74

 Directory of C:\

10/31/2017  12:06 AM    <DIR>          inetpub
09/29/2017  05:34 PM             1,894 License.txt
11/08/2017  06:26 AM    <SYMLINKD>     mnt [\\?\ContainerMappedDirectories\C033FFC2-6115-4A44-8A5B-DD2DFE13FC4C]
09/29/2017  12:28 PM    <DIR>          PerfLogs
10/12/2017  04:43 PM    <DIR>          Program Files
09/29/2017  12:28 PM    <DIR>          Program Files (x86)
10/31/2017  12:08 AM    <DIR>          RoslynCompilers
10/23/2017  10:52 PM           126,632 ServiceMonitor.exe
10/31/2017  12:07 AM    <DIR>          Users
10/31/2017  12:06 AM    <DIR>          Windows
               2 File(s)        128,526 bytes
               8 Dir(s)  21,230,841,856 bytes free

C:\>cd mnt
The parameter is incorrect.

Describe the results you expected:
I could explore mnt folder

Additional information you deem important (e.g. issue happens only occasionally):

I have identified this bug only exists in windows server 2016, RS3 image won’t have such issue.

Output of docker version:

c:\var\lib>docker version
Client:
 Version:      17.03.1-ee-3
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   3fcee33
 Built:        Thu Mar 30 19:31:22 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.03.1-ee-3
 API version:  1.27 (minimum version 1.24)
 Go version:   go1.7.5
 Git commit:   3fcee33
 Built:        Thu Mar 30 19:31:22 2017
 OS/Arch:      windows/amd64
 Experimental: false

Output of docker info:

c:\var\lib>docker info
Containers: 52
 Running: 7
 Paused: 0
 Stopped: 45
Images: 10
Server Version: 17.03.1-ee-3
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: l2bridge l2tunnel nat null overlay transparent
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 14393 (14393.1358.amd64fre.rs1_release.170602-2252)
Operating System: Windows Server 2016 Datacenter
OSType: windows
Architecture: x86_64
CPUs: 4
Total Memory: 14 GiB
Name: 33192acs9001
ID: VU22:O7EP:3TI7:3DBM:XAIS:2YZ3:6IRW:K6K4:4YPH:24CT:E4IA:6TEZ
Docker Root Dir: C:\ProgramData\docker
Debug Mode (client): false
Debug Mode (server): false
Username: jlex2008
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
@andyzhangx andyzhangx changed the title ContainerPath in -v mapping could only be a drive when hostPath is a symbolic link on Windows dir path in ContainerPath in -v mapping would fail when hostPath is a symbolic link on Windows Sep 6, 2017
@andyzhangx andyzhangx mentioned this issue Sep 6, 2017
Merged
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Sep 13, 2017
Merge pull request #51252 from andyzhangx/azuredisk-windows
39659ac 
Automatic merge from submit-queue

Azuredisk mount on windows node

**What this PR does / why we need it**:
This PR will enable azure disk on windows node, customer could create a pod mounted with azure disk on windows node. 
There are a few pending items still left:
1) Current fstype would be forced as NTFS, will change if there is such requirement
2) GetDeviceNameFromMount function is not implemented(empty) because in Linux, we could use "cat /proc/mounts" to read all mounting points in OS easily, but in Windows, there is no such place, I am still figuring out. The empty function would cause a few warning logging, but it will not affect the main logic now.

**Special notes for your reviewer**:
1. This PR depends on #51240, which allow windows mount path in config validation
2. There is a bug in docker on windows(moby/moby#34729), the ContainerPath could only be a drive letter now(e.g. D:), dir path would fail in the end.

The example pod with mount path is like below:

```
kind: Pod
apiVersion: v1
metadata:
  name: pod-uses-shared-hdd-5g
  labels:
    name: storage
spec:
  containers:
  - image: microsoft/iis
    name: az-c-01
    volumeMounts:
    - name: blobdisk01
      mountPath: 'F:'
  nodeSelector:
    beta.kubernetes.io/os: windows
  volumes:
  - name: blobdisk01
    persistentVolumeClaim:
      claimName: pv-dd-shared-hdd-5
```

**Release note**:

```release-note
@thaJeztah
Copy link
Member

ping @johnstep @friism ptal

@andyzhangx andyzhangx changed the title dir path in ContainerPath in -v mapping would fail when hostPath is a symbolic link on Windows volume mapping would fail when hostPath is a symbolic link and containerPath is a dir path on Windows Nov 7, 2017
@andyzhangx
Copy link
Author

I have identified this bug only exists in windows server 2016, RS3 image won’t have such issue.

@thaJeztah
Copy link
Member

@AndyZhang so the issue is resolved in RS3? If so, ok to close this one?

@PatrickLang
Copy link

Agreed - I think we can close with recommendation to use Windows Server version 1709

@thaJeztah
Copy link
Member

Thanks!

@andyzhangx andyzhangx changed the title volume mapping would fail when hostPath is a symbolic link and containerPath is a dir path on Windows volume mapping would fail when hostPath is a symbolic link to a drive and containerPath is a dir path on Windows Nov 8, 2017
@andyzhangx
Copy link
Author

@thaJeztah @PatrickLang unfortunately this bug still exists in RS3 image, it's not a so obvious issue though.
"volume mapping would fail when hostPath is a symbolic link to a drive and containerPath is a dir path on Windows, since I could not reopen this issue in moby, I opened a new one #35436 "

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
platform/windows version/17.03
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@thaJeztah @andyzhangx @GordonTheTurtle @PatrickLang