Change:
ginkgo.By("verifying that pod has the correct nodeSelector") framework.ExpectEqual(pod.Spec.NodeSelector["kubernetes.io/os"], "windows") <del> cmd := []string{"cmd", "/c", "echo windows-volume-test", ">", filePath} stdoutRW, stderrRW, errRW := f.ExecCommandInContainerWithFullOutput(podName, rwcontainerName, cmd...) msg := fmt.Sprintf("cmd: %v, stdout: %q, stderr: %q", cmd, stdoutRW, stderrRW) </del> <ins> ginkgo.By("verifying that pod can write to a volume with read/write access") writecmd := []string{"cmd", "/c", "echo windows-volume-test", ">", filePath} stdoutRW, stderrRW, errRW := f.ExecCommandInContainerWithFullOutput(podName, rwcontainerName, writecmd...) msg := fmt.Sprintf("cmd: %v, stdout: %q, stderr: %q", writecmd, stdoutRW, stderrRW) </ins> framework.ExpectNoError(errRW, msg) <del> _, stderr, _ := f.ExecCommandInContainerWithFullOutput(podName, containerName, cmd...) </del> <ins> ginkgo.By("verifying that pod will get an error when writing to a volume that is readonly") _, stderr, _ := f.ExecCommandInContainerWithFullOutput(podName, containerName, writecmd...) </ins> framework.ExpectEqual(stderr, "Access is denied.") <ins> ginkgo.By("verifying that pod can read from the the volume that is readonly") </ins> readcmd := []string{"cmd", "/c", "type", filePath} readout, readerr, err := f.ExecCommandInContainerWithFullOutput(podName, containerName, readcmd...) readmsg := fmt.Sprintf("cmd: %v, stdout: %q, stderr: %q", readcmd, readout, readerr)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- Kubernetes e2e suite: [sig-windows] [Feature:Windows] Windows volume mounts check volume mount permissions container should have readOnly permissions on hostMapPath Feb 23 14:59:47.591: FAIL: cmd: [cmd /c echo windows-volume-test C:tmptest-file], stdout: "", stderr: "Access is denied."
/sig windows
/assign
Looks like it's a flaky test instead of a failing test /cc
mentioned this could be related to permissions: There might be two things happening, the test isn't actually waiting for pod to start (which is why it passes sometimes) and but when it does start it fails the test due to the permissions
` is used for creating the pods. According to the comments, the Pods should be up and running:
On successful run, I see the following in the kubelet logs: I believe we're execing into the pod when the container is actually getting deleted by containerd but the pod is running which is not giving a correct indication of the command. I am modifying the test to ensure we would wait till all the containers are Ready and log the stdout and stderr to see if we're noticing issues. I tried manually running this test on a Windows node but couldn't reproduce it.
More examples of flaking runs:
/assign
I ran the test continuously: I am guessing this might be due to some of resources constraints we have seen when other tests runs at the same time (such as ). looking into it further...
Maybe we can convert it to a serial test case?
maybe, slowly looking into is some more... I find it interesting that which essentially does the same thing
Here's another:
Figured out what is happening: If the test runs before it leaves a file behind that the new test doesn't have permissions to. To repo: Then run:
/triage accepted