Docker error response from daemon user declined directory sharing - Исправление ошибок и поиск оптимальных решений проблем

While trying to run this command :

docker-compose up

I get this error :

Error response from daemon: user declined directory sharing C:Userspath_to_my_folder

I am working on windows 10

asked Jan 27, 2022 at 11:26

You have to add C:Userspath_to_my_folder to Docker Filesharing.
Go to docker dashboard -> settings ->Resources -> FileSharing.
Add required folder and hit Apply & Restart.

answered Jan 30, 2022 at 23:53

Normally, Docker will display a desktop notification asking for your confirmation before sharing the folder.

However, if notifications are disabled (for example, if you enabled Focus Assist), the confirmation box won’t show and Docker will automatically decline the permission.

answered Apr 28, 2022 at 11:51

Benoit BlanchonBenoit Blanchon

12.8k4 gold badges69 silver badges76 bronze badges

Open Docker and follow this -> settings ->Resources -> FileSharing. Add required folder and hit Apply & Restart

answered May 26, 2022 at 22:54

Источник

Содержание

How to solve Error: docker: Error response from daemon: the working directory is invalid
1 Answer 1
docker.exe Error response from daemon Drive sharing failed for an unknown reason #3035
Comments
Expected behavior
Actual behavior
Information
Steps to reproduce the behavior
log.txt
My Env
Troubleshoot topics
Topics for all platforms
Make sure certificates are set up correctly
Topics for Linux and Mac
Volume mounting requires file sharing for any project directories outside of $HOME
Docker Desktop fails to start on MacOS or Linux platforms
Topics for Mac
Incompatible CPU detected
Topics for Windows
Volumes
Permissions errors on data directories for shared volumes
Volume mounting requires shared folders for Linux containers
Support for symlinks
Avoid unexpected syntax errors, use Unix style line endings for files in containers
Path conversion on Windows
Working with Git Bash
Virtualization
WSL 2 and Windows Home
Hyper-V
Virtualization must be enabled
Hypervisor enabled at Windows startup
Windows containers and Windows Server
Networking issues
2.4.0.0 can’t mount file into container: Error response from daemon: not a directory #8878
Comments

How to solve Error: docker: Error response from daemon: the working directory is invalid

I am just starting to use Jenkins and Docker in Windows10. Currently I have installed both Jenkins and Docker and created a Dockerfile and a Jenkinsfile

Unfortunately whenever I try to build in Jenkins I keep getting an error. Below is the Jenkin logs

Dockerfile

Jenkinsfile

I am building a node application built using Angular

1 Answer 1

Your Dockerized Jenkins instance is attempting to use the Docker API to spin up a new Docker container to do your build in. This Docker API it wants to talk to is the same Docker daemon that Jenkins itself is running in.

On a normal Docker daemon running on Linux, you would simply pass in the Docker socket at /var/run/docker.sock as a volume to the Jenkins container (e.g. a -v /var/run/docker.sock:/var/run/docker.sock argument to your docker run command).

However, on Docker for Windows, you are running Docker in a Linux VM on Windows (either by WSL2 or Hyper-V). Depending on how you have your Docker environment setup, you can try to bind the Docker socket in your Jenkins container using one of the following:

-v /var/run/docker.sock:/var/run/docker.sock
-v //var/run/docker.sock:/var/run/docker.sock
-v tcp://127.0.0.1:2376:/var/run/docker.sock

I’ve seen some solutions do this in addition to one of the above, in order to perform some hacks for Docker for Windows:

Or, a better solution that requires less hacks: Do this in a proper Linux OS install. Docker for Windows should not be used in production environments.

Источник

docker.exe Error response from daemon Drive sharing failed for an unknown reason #3035

[ Stable ] I have tried with the latest version of my channel (Stable or Edge)
[ Yes ] I have uploaded Diagnostics
Diagnostics ID: 9CD2F59F-7D3C-416A-993C-2B0A74F46995/20181205154030

Expected behavior

Actual behavior

docker.exe Error response from daemon Drive sharing failed for an unknown reason.

Information

Windows Version:
Docker for Windows Version:

Steps to reproduce the behavior

Docker —> Settings.
Chose D to share for example( drive C is the same).
Input OS passwords.
Then docker restarted.
But D is also not shared.

log.txt

[15:48:19.144][SambaShare ][Error ] Unable to mount D drive: 10.22.33.1 (10.22.33.1:445) open
rm: cannot remove ‘/d’: No such file or directory
rm: cannot remove ‘/D’: No such file or directory
umount: /host_mnt/d: not mounted.
mount.cifs kernel mount options:
ip=10.22.33.1,unc=10.22.33.1D,noperm,iocharset=utf8,dir_mode=0777,nobrl,mfsymlinks,vers=3.02,sec=ntlmsspi,user=higkoo,domain=BILIOPS,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) `

My Env

Microsoft Windows [Version 10.0.17134.407]
Client: Docker Engine — Community
Version: 18.09.0
API version: 1.39
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:47:51 2018
OS/Arch: windows/amd64
Experimental: false

Server: Docker Engine — Community
Engine:
Version: 18.09.0
API version: 1.39 (minimum version 1.12)
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:55:00 2018
OS/Arch: linux/amd64
Experimental: false

The text was updated successfully, but these errors were encountered:

Источник

Troubleshoot topics

Topics for all platforms

Make sure certificates are set up correctly

Docker Desktop ignores certificates listed under insecure registries, and does not send client certificates to them. Commands like docker run that attempt to pull from the registry produces error messages on the command line, like this:

As well as on the registry. For example:

Topics for Linux and Mac

Volume mounting requires file sharing for any project directories outside of $HOME

If you are using mounted volumes and get runtime errors indicating an application file is not found, access to a volume mount is denied, or a service cannot start, such as when using Docker Compose, you might need to enable file sharing.

Volume mounting requires shared drives for projects that live outside of the /home/ directory. From Settings, select Resources and then File sharing. Share the drive that contains the Dockerfile and volume.

Docker Desktop fails to start on MacOS or Linux platforms

On MacOS and Linux, Docker Desktop creates Unix domain sockets used for inter-process communication.

Docker fails to start if the absolute path length of any of these sockets exceeds the OS limitation which is 104 characters on MacOS and 108 characters on Linux. These sockets are created under the userвЂ™s home directory. If the user ID length is such that the absolute path of the socket exceeds the OS path length limitation, then Docker Desktop is unable to create the socket and fails to start. The workaround for this is to shorten the user ID which we recommend has a maximum length of 33 characters on MacOS and 55 characters on Linux.

Following are the examples of errors on MacOS which indicate that the startup failure was due to exceeding the above mentioned OS limitation:

Topics for Mac

Incompatible CPU detected

Docker Desktop requires a processor (CPU) that supports virtualization and, more specifically, the Apple Hypervisor framework. Docker Desktop is only compatible with Mac systems that have a CPU that supports the Hypervisor framework. Most Macs built in 2010 and later support it,as described in the Apple Hypervisor Framework documentation about supported hardware:

Generally, machines with an Intel VT-x feature set that includes Extended Page Tables (EPT) and Unrestricted Mode are supported.

To check if your Mac supports the Hypervisor framework, run the following command in a terminal window.

If your Mac supports the Hypervisor Framework, the command prints kern.hv_support: 1 .

If not, the command prints kern.hv_support: 0 .

See also, Hypervisor Framework Reference in the Apple documentation, and Docker Desktop Mac system requirements.

Topics for Windows

Volumes

Permissions errors on data directories for shared volumes

When sharing files from Windows, Docker Desktop sets permissions on shared volumes to a default value of 0777 ( read , write , execute permissions for user and for group ).

The default permissions on shared volumes are not configurable. If you are working with applications that require permissions different from the shared volume defaults at container runtime, you need to either use non-host-mounted volumes or find a way to make the applications work with the default file permissions.

Volume mounting requires shared folders for Linux containers

If you are using mounted volumes and get runtime errors indicating an application file is not found, access is denied to a volume mount, or a service cannot start, such as when using Docker Compose, you might need to enable shared folders.

With the Hyper-V backend, mounting files from Windows requires shared folders for Linux containers. From Settings, select Shared Folders and share the folder that contains the Dockerfile and volume.

Support for symlinks

Symlinks work within and across containers. To learn more, see How do symlinks work on Windows?.

Avoid unexpected syntax errors, use Unix style line endings for files in containers

Any file destined to run inside a container must use Unix style n line endings. This includes files referenced at the command line for builds and in RUN commands in Docker files.

Docker containers and docker build run in a Unix environment, so files in containers must use Unix style line endings: n , not Windows style: rn . Keep this in mind when authoring files such as shell scripts using Windows tools, where the default is likely to be Windows style line endings. These commands ultimately get passed to Unix commands inside a Unix based container (for example, a shell script passed to /bin/sh ). If Windows style line endings are used, docker run fails with syntax errors.

For an example of this issue and the resolution, see this issue on GitHub: Docker RUN fails to execute shell script.

Path conversion on Windows

On Linux, the system takes care of mounting a path to another path. For example, when you run the following command on Linux:

It adds a /work directory to the target container to mirror the specified path.

However, on Windows, you must update the source path. For example, if you are using the legacy Windows shell ( cmd.exe ), you can use the following command:

This starts the container and ensures the volume becomes usable. This is possible because Docker Desktop detects the Windows-style path and provides the appropriate conversion to mount the directory.

Docker Desktop also allows you to use Unix-style path to the appropriate format. For example:

Working with Git Bash

Git Bash (or MSYS) provides a Unix-like environment on Windows. These tools apply their own preprocessing on the command line. For example, if you run the following command in Git Bash, it gives an error:

This is because the character has a special meaning in Git Bash. If you are using Git Bash, you must neutralize it using \ :

Also, in scripts, the pwd command is used to avoid hardcoding file system locations. Its output is a Unix-style path.

Combined with the $() syntax, the command below works on Linux, however, it fails on Git Bash.

You can work around this issue by using an extra /

Portability of the scripts is not affected as Linux treats multiple / as a single entry. Each occurence of paths on a single line must be neutralized.

In this example, The $(pwd) is not converted because of the preceding вЂ/вЂ™. However, the second вЂ/workвЂ™ is transformed by the POSIX layer before passing it to Docker Desktop. You can also work around this issue by using an extra / .

To verify whether the errors are generated from your script, or from another source, you can use an environment variable. For example:

It only expects the environment variable here. The value doesnвЂ™t matter.

In some cases, MSYS also transforms colons to semicolon. Similar conversions can also occur when using

because the POSIX layer translates it to a DOS path. MSYS_NO_PATHCONV also works in this case.

Virtualization

Your machine must have the following features for Docker Desktop to function correctly.

WSL 2 and Windows Home

Virtual Machine Platform
Windows Subsystem for Linux
Virtualization enabled in the BIOS
Hypervisor enabled at Windows startup

Hyper-V

On Windows 10 Pro or Enterprise, you can also use Hyper-V with the following features enabled:

Docker Desktop requires Hyper-V as well as the Hyper-V Module for Windows Powershell to be installed and enabled. The Docker Desktop installer enables it for you.

Docker Desktop also needs two CPU hardware features to use Hyper-V: Virtualization and Second Level Address Translation (SLAT), which is also called Rapid Virtualization Indexing (RVI). On some systems, Virtualization must be enabled in the BIOS. The steps required are vendor-specific, but typically the BIOS option is called Virtualization Technology (VTx) or something similar. Run the command systeminfo to check all required Hyper-V features. See Pre-requisites for Hyper-V on Windows 10 for more details.

To install Hyper-V manually, see Install Hyper-V on Windows 10. A reboot is required after installation. If you install Hyper-V without rebooting, Docker Desktop does not work correctly.

From the start menu, type Turn Windows features on or off and press enter. In the subsequent screen, verify that Hyper-V is enabled.

Virtualization must be enabled

In addition to Hyper-V or WSL 2, virtualization must be enabled. Check the Performance tab on the Task Manager:

If you manually uninstall Hyper-V, WSL 2 or disable virtualization, Docker Desktop cannot start. See Unable to run Docker for Windows on Windows 10 Enterprise.

Hypervisor enabled at Windows startup

If you have completed the steps described above and are still experiencing Docker Desktop startup issues, this could be because the Hypervisor is installed, but not launched during Windows startup. Some tools (such as older versions of Virtual Box) and video game installers disable hypervisor on boot. To reenable it:

Open an administrative console prompt.
Run bcdedit /set hypervisorlaunchtype auto .
Restart Windows.

You can also refer to the Microsoft TechNet article on Code flow guard (CFG) settings.

Windows containers and Windows Server

Docker Desktop is not supported on Windows Server. If you have questions about how to run Windows containers on Windows 10, see Switch between Windows and Linux containers.

You can install a native Windows binary which allows you to develop and run Windows containers without Docker Desktop. However, if you install Docker this way, you cannot develop or run Linux containers. If you try to run a Linux container on the native Docker daemon, an error occurs:

Networking issues

IPv6 is not (yet) supported on Docker Desktop.

Источник

2.4.0.0 can’t mount file into container: Error response from daemon: not a directory #8878

After update to 2.4.0.0 dont work file mount, only work directory mount.

Error response from daemon: not a directory

After downgrade to 2.3.0.5 files mount works!

The text was updated successfully, but these errors were encountered:

Thanks for the report, @4n70w4. Does it work if you try it with docker run -v instead of using compose?

After downgrade to 2.3.0.5 files mount works!

@4n70w4 Were you able to downgrade without losing all your volumes / etc? would you mind documenting how you did the downgrade?

Does it work if you try it with docker run -v instead of using compose?

@stephen-turner For me, it’s broken with the same error as compose.

Docker version 20.10.0, build 7287ab3
Docker desktop 3.0.0 (50684)

@adam12 I haven’t used volumes, only mounts. I deleted the old version and all files were deleted along with it. The new installation was visually clean. I use for development, so the loss is not terrible.

My setup:
Docker version 19.03.13, build 4484c46d9d
Docker desktop 3.0.0 (50684)

No problems with mounting files.

Could this be related to #9823 ?

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

Источник

Add Answer
|
View In TPC Matrix

Technical Problem Cluster First Answered On
June 23, 2022

Popularity
4/10

Helpfulness
2/10

Contributions From The Grepper Developer Community

Code Examples

docker: Error response from daemon: user declined directory sharing C:workspace.

TPC Matrix View Full Screen

docker: Error response from daemon: user declined directory sharing C:workspace.

Comment

Popularity
4/10 Helpfulness
2/10
Language
whatever

Source: forums.docker.com

Tags: directory
response
sharing
whatever

Contributed on Jun 23 2022

Ryan Downer

2 Answers Avg Quality 3/10

Источник

[ Stable ] I have tried with the latest version of my channel (Stable or Edge)
[ Yes ] I have uploaded Diagnostics
Diagnostics ID: 9CD2F59F-7D3C-416A-993C-2B0A74F46995/20181205154030

Expected behavior

Mount shared drives.

Actual behavior

docker.exe Error response from daemon Drive sharing failed for an unknown reason.

Information

Windows Version:
Docker for Windows Version:

Steps to reproduce the behavior

Docker —> Settings.
Chose D to share for example( drive C is the same).
Input OS passwords.
Then docker restarted.
But D is also not shared.

log.txt

[15:48:19.144][SambaShare ][Error ] Unable to mount D drive: 10.22.33.1 (10.22.33.1:445) open
rm: cannot remove ‘/d’: No such file or directory
rm: cannot remove ‘/D’: No such file or directory
umount: /host_mnt/d: not mounted.
mount.cifs kernel mount options:
ip=10.22.33.1,unc=10.22.33.1D,noperm,iocharset=utf8,dir_mode=0777,nobrl,mfsymlinks,vers=3.02,sec=ntlmsspi,user=higkoo,domain=BILIOPS,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) `

My Env

Microsoft Windows [Version 10.0.17134.407]
Client: Docker Engine — Community
Version: 18.09.0
API version: 1.39
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:47:51 2018
OS/Arch: windows/amd64
Experimental: false

Server: Docker Engine — Community
Engine:
Version: 18.09.0
API version: 1.39 (minimum version 1.12)
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:55:00 2018
OS/Arch: linux/amd64
Experimental: false

Источник

I am just starting to use Jenkins and Docker in Windows10. Currently I have installed both Jenkins and Docker and created a Dockerfile and a Jenkinsfile

Unfortunately whenever I try to build in Jenkins I keep getting an error. Below is the Jenkin logs

Branch indexing
12:48:47 Connecting to https://api.github.com with no credentials, anonymous access
Obtained Jenkinsfile from 87252353bfae9210f07a234b6af7d17b6aee1363
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in C:Usersoko.jenkinsworkspaces-contest_ft-jenkins-integration
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
The recommended git tool is: NONE
No credentials specified
 > git.exe rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git.exe config remote.origin.url https://github.com/FurahaSolutions/fs-online-maths-contest.git # timeout=10
Fetching without tags
Fetching upstream changes from https://github.com/FurahaSolutions/fs-online-maths-contest.git
 > git.exe --version # timeout=10
 > git --version # 'git version 2.23.0.windows.1'
 > git.exe fetch --no-tags --force --progress -- https://github.com/FurahaSolutions/fs-online-maths-contest.git +refs/heads/ft-jenkins-integration:refs/remotes/origin/ft-jenkins-integration # timeout=10
Checking out Revision 87252353bfae9210f07a234b6af7d17b6aee1363 (ft-jenkins-integration)
 > git.exe config core.sparsecheckout # timeout=10
 > git.exe checkout -f 87252353bfae9210f07a234b6af7d17b6aee1363 # timeout=10
Commit message: "Added Dockerfile"
 > git.exe rev-list --no-walk 036200096bf00516e0a8b149541ba994efcd360a # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] isUnix
[Pipeline] bat

[m[32m]9;8;"USERNAME"@]9;8;"COMPUTERNAME" [92mC:Usersoko.jenkinsworkspaces-contest_ft-jenkins-integration[90m
[90m>[m ]9;12docker inspect -f . node:latest 
.
[Pipeline] withDockerContainer
Jenkins does not seem to be running inside a container
$ docker run -d -t -w C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration/ -v C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration/:C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration/ -v C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration@tmp/:C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration@tmp/ -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** node:latest cmd.exe
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
java.io.IOException: Failed to run image 'node:latest'. Error: docker: Error response from daemon: the working directory 'C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration/' is invalid, it needs to be an absolute path.
See 'docker run --help'.
    at org.jenkinsci.plugins.docker.workflow.client.WindowsDockerClient.run(WindowsDockerClient.java:58)
    at org.jenkinsci.plugins.docker.workflow.WithContainerStep$Execution.start(WithContainerStep.java:198)
    at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:319)
    at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:193)
    at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:20)
    at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(Docker.groovy:126)
    at org.jenkinsci.plugins.docker.workflow.Docker.node(Docker.groovy:66)
    at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(Docker.groovy:114)
    at org.jenkinsci.plugins.docker.workflow.declarative.DockerPipelineScript.runImage(DockerPipelineScript.groovy:57)
    at org.jenkinsci.plugins.docker.workflow.declarative.AbstractDockerPipelineScript.configureRegistry(AbstractDockerPipelineScript.groovy:73)
    at org.jenkinsci.plugins.docker.workflow.declarative.AbstractDockerPipelineScript.run(AbstractDockerPipelineScript.groovy:51)
    at org.jenkinsci.plugins.pipeline.modeldefinition.agent.CheckoutScript.checkoutAndRun(CheckoutScript.groovy:61)
    at ___cps.transform___(Native Method)
    at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:86)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:113)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:83)
    at sun.reflect.GeneratedMethodAccessor487.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
    at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46)
    at com.cloudbees.groovy.cps.Next.step(Next.java:83)
    at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
    at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
    at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
    at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
    at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
    at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:185)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:400)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$400(CpsThreadGroup.java:96)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:312)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:276)
    at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:67)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:139)
    at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
    at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Finished: FAILUREBranch indexing
12:48:47 Connecting to https://api.github.com with no credentials, anonymous access
Obtained Jenkinsfile from 87252353bfae9210f07a234b6af7d17b6aee1363
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in C:Usersoko.jenkinsworkspaces-contest_ft-jenkins-integration
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
The recommended git tool is: NONE
No credentials specified
 > git.exe rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git.exe config remote.origin.url https://github.com/FurahaSolutions/fs-online-maths-contest.git # timeout=10
Fetching without tags
Fetching upstream changes from https://github.com/FurahaSolutions/fs-online-maths-contest.git
 > git.exe --version # timeout=10
 > git --version # 'git version 2.23.0.windows.1'
 > git.exe fetch --no-tags --force --progress -- https://github.com/FurahaSolutions/fs-online-maths-contest.git +refs/heads/ft-jenkins-integration:refs/remotes/origin/ft-jenkins-integration # timeout=10
Checking out Revision 87252353bfae9210f07a234b6af7d17b6aee1363 (ft-jenkins-integration)
 > git.exe config core.sparsecheckout # timeout=10
 > git.exe checkout -f 87252353bfae9210f07a234b6af7d17b6aee1363 # timeout=10
Commit message: "Added Dockerfile"
 > git.exe rev-list --no-walk 036200096bf00516e0a8b149541ba994efcd360a # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] isUnix
[Pipeline] bat

[m[32m]9;8;"USERNAME"@]9;8;"COMPUTERNAME" [92mC:Usersoko.jenkinsworkspaces-contest_ft-jenkins-integration[90m
[90m>[m ]9;12docker inspect -f . node:latest 
.
[Pipeline] withDockerContainer
Jenkins does not seem to be running inside a container
$ docker run -d -t -w C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration/ -v C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration/:C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration/ -v C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration@tmp/:C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration@tmp/ -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** node:latest cmd.exe
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
java.io.IOException: Failed to run image 'node:latest'. Error: docker: Error response from daemon: the working directory 'C:/Users/oko/.jenkins/workspace/s-contest_ft-jenkins-integration/' is invalid, it needs to be an absolute path.
See 'docker run --help'.
    at org.jenkinsci.plugins.docker.workflow.client.WindowsDockerClient.run(WindowsDockerClient.java:58)
    at org.jenkinsci.plugins.docker.workflow.WithContainerStep$Execution.start(WithContainerStep.java:198)
    at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:319)
    at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:193)
    at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:20)
    at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(Docker.groovy:126)
    at org.jenkinsci.plugins.docker.workflow.Docker.node(Docker.groovy:66)
    at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(Docker.groovy:114)
    at org.jenkinsci.plugins.docker.workflow.declarative.DockerPipelineScript.runImage(DockerPipelineScript.groovy:57)
    at org.jenkinsci.plugins.docker.workflow.declarative.AbstractDockerPipelineScript.configureRegistry(AbstractDockerPipelineScript.groovy:73)
    at org.jenkinsci.plugins.docker.workflow.declarative.AbstractDockerPipelineScript.run(AbstractDockerPipelineScript.groovy:51)
    at org.jenkinsci.plugins.pipeline.modeldefinition.agent.CheckoutScript.checkoutAndRun(CheckoutScript.groovy:61)
    at ___cps.transform___(Native Method)
    at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:86)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:113)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:83)
    at sun.reflect.GeneratedMethodAccessor487.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
    at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46)
    at com.cloudbees.groovy.cps.Next.step(Next.java:83)
    at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
    at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
    at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
    at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
    at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
    at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:185)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:400)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$400(CpsThreadGroup.java:96)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:312)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:276)
    at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:67)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:139)
    at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
    at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Finished: FAILURE

Dockerfile

# Stage 1

FROM node:10-alpine as build-step

RUN mkdir -p /app

WORKDIR /app

COPY package.json /app

RUN npm install

COPY . /app

RUN npm run build --prod


# Stage 2

FROM nginx:1.17.1-alpine

COPY --from=build-step /app/docs /usr/share/nginx/html

Jenkinsfile

pipeline {
  agent {
    docker { image 'node:latest' }
  }
  stages {
    stage('Install') {
      steps { bat 'npm install' }
    }

    stage('Test') {
      parallel {
        stage('Static code analysis') {
            steps { bat 'npm run-script lint' }
        }
        stage('Unit tests') {
            steps { bat 'npm run-script test' }
        }
      }
    }

    stage('Build') {
      steps { bat 'npm run-script build' }
    }
  }
}

I am building a node application built using Angular

asked Dec 18, 2020 at 10:09

On a normal Docker daemon running on Linux, you would simply pass in the Docker socket at /var/run/docker.sock as a volume to the Jenkins container (e.g. a -v /var/run/docker.sock:/var/run/docker.sock argument to your docker run command).

-v /var/run/docker.sock:/var/run/docker.sock
-v //var/run/docker.sock:/var/run/docker.sock
-v tcp://127.0.0.1:2376:/var/run/docker.sock

I’ve seen some solutions do this in addition to one of the above, in order to perform some hacks for Docker for Windows:

-v /usr/local/bin/docker:/usr/bin/docker

Or, a better solution that requires less hacks: Do this in a proper Linux OS install. Docker for Windows should not be used in production environments.

answered Jan 19, 2021 at 18:20

staehlestaehle

6755 silver badges11 bronze badges

Источник

Error response from daemon drive sharing is blocked by a firewall

by Vladimir Popescu

Being an artist his entire life while also playing handball at a professional level, Vladimir has also developed a passion for all things computer-related. With an innate fascination… read more

Updated on June 22, 2020

XINSTALL BY CLICKING THE DOWNLOAD FILE

To fix various PC problems, we recommend DriverFix:
This software will keep your drivers up and running, thus keeping you safe from common computer errors and hardware failure. Check all your drivers now in 3 easy steps:

Download DriverFix (verified download file).
Click Start Scan to find all problematic drivers.
Click Update Drivers to get new versions and avoid system malfunctionings.

DriverFix has been downloaded by 0 readers this month.

A large number of users have reported encountering the error message saying Windows 10 error response from daemon drive sharing seems blocked by a firewall.

This means that you can not use Docker like you normally would. Having this issue can be extremely annoying, especially because of the entire access restriction caused in this case.

One of the most common causes for this error is the Norton Antivirus Firewall, and in today’s article, we’ll show you how to fix the issue.

How to fix Error response from daemon drive sharing is blocked by a firewall?

1. Update Docker to the latest version

Click here to download the latest Docker version.
Run the installer software on your PC and follow the on-screen instructions in order to complete the setup.
Check to see if this fixed your issue.
If the issue persists, please follow the next method.

2. Change the Network Interface Card properties

Press Windows Key+X keys on your keyboard -> click on Settings.
Inside the Settings window -> select Network and Internet.
Choose the option Network and Sharing Center.
Click on Change adapter settings.
Right-click the Network Interface Card connection -> select Properties.
Uninstall and reinstall the service File and Printer Sharing for Microsoft Network.
Check to see if this method fixes your problem.

File Sharing is blocked by Windows Firewall? Fix that with this simple guide!

3. Use PowerShell (Admin) to set the DockerNAT service to private

Press Windows Key+X keys on your keyboard -> select PowerShell (Admin).
Inside the PowerShell window -> type in the following command and press Enter: Set-NetConnectionProfile -interfacealias "vEthernet (DockerNAT)" -NetworkCategory Private
Open Docker and navigate to the Settings window.
Enable drives C and D for sharing.

4. Reset the Norton Antivirus firewall service

Open Norton Antivirus software -> click on Settings.
Inside the Settings window -> click Firewall.
In the General Settings tab -> click Reset in the Firewall Reset row.
Check to see if this solved your issue.

5. Allow DockerNAT executable through the firewall

Click on the Cortana search box -> type firewall -> select the first option in the list.
In the Firewall settings -> select the option Allow an app or feature through Windows Defender Firewall.
Search for DockerNAT on the list and make sure to permit connections (incoming and outgoing).
Save the settings and check if the issue is resolved.

In this guide, we explored the best methods to deal with the issue caused by the error Response from daemon drive sharing seems blocked by a firewall on Windows 10.

Please feel free to let us know if this guide helped you by commenting below.

Still having issues? Fix them with this tool:

SPONSORED

If the advices above haven’t solved your issue, your PC may experience deeper Windows problems. We recommend downloading this PC Repair tool (rated Great on TrustPilot.com) to easily address them. After installation, simply click the Start Scan button and then press on Repair All.

Источник

How to solve Error: docker: Error response from daemon: the working directory is invalid

1 Answer 1

docker.exe Error response from daemon Drive sharing failed for an unknown reason #3035

Expected behavior

Actual behavior

Information

Steps to reproduce the behavior

log.txt

My Env

Troubleshoot topics

Topics for all platforms

Make sure certificates are set up correctly

Topics for Linux and Mac

Volume mounting requires file sharing for any project directories outside of $HOME

Docker Desktop fails to start on MacOS or Linux platforms

Topics for Mac

Incompatible CPU detected

Topics for Windows

Volumes

Permissions errors on data directories for shared volumes

Volume mounting requires shared folders for Linux containers

Support for symlinks

Avoid unexpected syntax errors, use Unix style line endings for files in containers

Path conversion on Windows

Working with Git Bash

Virtualization

WSL 2 and Windows Home

Hyper-V

Virtualization must be enabled

Hypervisor enabled at Windows startup

Windows containers and Windows Server

Networking issues

2.4.0.0 can’t mount file into container: Error response from daemon: not a directory #8878

Contents

Code Examples

Related Problems

TPC Matrix View Full Screen

docker: Error response from daemon: user declined directory sharing C:workspace.

Expected behavior

Actual behavior

Information

Steps to reproduce the behavior

log.txt

My Env

How to fix Error response from daemon drive sharing is blocked by a firewall?

1. Update Docker to the latest version

2. Change the Network Interface Card properties

3. Use PowerShell (Admin) to set the DockerNAT service to private

4. Reset the Norton Antivirus firewall service

5. Allow DockerNAT executable through the firewall

Newsletter