Error: Unable to find good bind path format

[tainguyen206]

This issue just started to happen to me when packaging package with docker: I couldn't find answer anywhere. Not sure if this is with serverless or this plugin.

Error: Unable to find good bind path format

at getBindPath (C:\Users\taing\Desktop\projects\wm-tc\node_modules\serverless-python-requirements\lib\docker.js:109:9)
at installRequirements (C:\Users\taing\Desktop\projects\wm-tc\node_modules\serverless-python-requirements\lib\pip.js:92:22)
at values.filter.map.f (C:\Users\taing\Desktop\projects\wm-tc\node_modules\serverless-python-requirements\lib\pip.js:226:11)
at Array.map (<anonymous>)
at ServerlessPythonRequirements.installAllRequirements (C:\Users\taing\Desktop\projects\wm-tc\node_modules\serverless-python-requirements\lib\pip.js:221:8)

From previous event: at PluginManager.invoke (C:\Users\taing\AppData\Roaming\npm\node_modules\serverless\lib\classes\PluginManager.js:372:22) at PluginManager.run (C:\Users\taing\AppData\Roaming\npm\node_modules\serverless\lib\classes\PluginManager.js:403:17) at variables.populateService.then (C:\Users\taing\AppData\Roaming\npm\node_modules\serverless\lib\Serverless.js:102:33) at runCallback (timers.js:696:18) at tryOnImmediate (timers.js:667:5) at processImmediate (timers.js:649:5) at process.topLevelDomainCallback (domain.js:121:23) From previous event: at Serverless.run (C:\Users\taing\AppData\Roaming\npm\node_modules\serverless\lib\Serverless.js:89:74) at serverless.init.then (C:\Users\taing\AppData\Roaming\npm\node_modules\serverless\bin\serverless:42:50)

[dschep]

cc @kichik

[kichik]

Please include the following information:

• Version of serverless-python-requirements used
• Output of docker version
• Output of docker run --rm -v c:/Users/taing:/test busybox ls -lah /test
• Output of docker run --rm -v /c/Users/taing:/test busybox ls -lah /test
• Any recent changes you've made. Did this start after a version upgrade? Docker upgrade? Windows update?

[tainguyen206]

I did have windows update recently but not sure about docker.

I did update serverless-python-requirements recently as well. But not sure if it's related.

4.1.0

docker version: `Client: Version: 18.03.1-ce API version: 1.37 Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:12:48 2018 OS/Arch: windows/amd64 Experimental: false Orchestrator: swarm

Server: Engine: Version: 18.03.1-ce API version: 1.37 (minimum version 1.12) Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:22:38 2018 OS/Arch: linux/amd64 Experimental: false`

docker run --rm -v c:/Users/taing:/test busybox ls -lah /test total 4 drwxr-xr-x 3 root root 60 Jun 20 21:13 . drwxr-xr-x 1 root root 4.0K Jun 20 21:30 .. drwxr-xr-x 3 root root 60 Jun 20 21:13 Desktop

docker run --rm -v /c/Users/taing:/test busybox ls -lah /test total 4 drwxr-xr-x 3 root root 60 Jun 20 21:13 . drwxr-xr-x 1 root root 4.0K Jun 20 21:31 .. drwxr-xr-x 3 root root 60 Jun 20 21:13 Desktop

[kichik]

That's weird. Everything seems in place. What version did you use before this? Also, please paste the output of:

docker run --rm -v c:/Users/taing/Desktop/projects/wm-tc:/test alpine ls /test/serverless.yml

If you want to help debugging this, lib/pip.js line 40 could have some debug prints. Specifically you can print ps.stdout and if any exception is caught. That's the part that seems to be failing for you.

[mrpgraae]

I had this error as well and managed to figure it out. the tryBindPath function in /lib/docker.js assumes that the serverless config file is called serverless.yml, in my case it was called serverless.yaml. So for a quick fix, just change the name of that file.

Since Serverless accepts configs with the .yaml extension, they should probably also be supported by this plugin.

[illagrenan]

I had the same problem after clean installation of serverless and serverless-python-requirements.

How I fixed this:

1. Open Docker for Windows
2. Go to Shared Drives
3. Make sure C is shared. If C is already shared, un-share it and share it again

[kichik]

@mrpgraae I've created a PR for that #213. @illagrenan that should already be covered by the documentation, but it would be nice to detect it and print a good error message. That said, I don't think that's what @lucasnp had because they were able to confirm file sharing is working.

[mrpgraae]

@kichik That was fast! Thank you for the nice plugin btw. Works great, now that I got around the filename issue 😄

[dschep]

Closed by #213

@mrpgraae (should've asked before i merged, oh well). could you test this? install this plugin with

npm i UniteIncome/serverless-python-requirements

[jfaraklit]

I have the same issue. The filename is not an issue in my end. What else could go wrong to get this error? I am on windows and my docker seems to be working fine.

[AndrewFarley]

Hey Windows-ey guys and other contributors. I was looking at this getBindPath function, and recently used it in my PR and found it... a bit lacking. It currently just searches through a list of files we expect to be there, shouldn't this function be modified to CREATE a file at the start of it which it then can test mounting in Docker, and then delete that file afterwards? It seems a bit... silly, to have to check all the different possible files that might be there, and additionally its current implementation is then limited to only a folder that contains serverless repos, not any folder, as it should be imho. I almost made this modification in #165 but decided against it for now. I'd love some thoughts/input/feedback before I just go and do it, wouldn't that be smarter?

[kichik]

I prefer not changing things when possible. You don't always have permissions, sometimes you crash and leave things behind, and in this case there should always be a file we know.

[AndrewFarley]

@kichik If you don't have permissions, then you won't be able to use this plugin, as it writes to the .serverless folder at the very least. So, I strongly disagree. :P . I was thinking just a hidden-ey file. .slspy-getBindPathHelper or so. For my MR to be possible on Windows, I had to add "requirements.txt" to that list, and then every cache folder I make that mounts "touch" a requirements.txt file in there just to get that getBindPath helper to work. That seems like a huge fail, no? Technically, with what I did in my MR, I'm bascially already doing this, but not inside the function. All I'm proposing is to make this function smarter

[kichik]

That specific part was a general comment. But it might apply to this plugin in the future. Someone might ask for a feature where the build folder is different than the source folder. It's a common request that helps make cleaner CI systems.

I am not following why you had to add requirements.txt to the list. Are you using the helper for something new? I haven't looked at your code.

[AndrewFarley]

So, that is EXACTLY what my MR does, already. The MR does building of pip requirements (and thus volume mounting) from a folder other than your serverless folder, which I needed for two reasons, one for CI/CD systems, and 2: for caching the output (static cache) from pip. It no longer mounts your entire project path into Docker unnecessarily for building requirements, it uses an AppDir temporary/cache folder from your user/system/home/temp/vars, and/or you can specify your own path (for Ci/CD systems, with shared cache). This concept, however, falls apart with the current implementation of getBindPath because that only currently supports a serverless directory. Hence, my "touch" hack, and hence my proposal to make it smarter/better.

Because what you said above is true... think about what you said... if you can't write to some path, why would you ever want to volume mount that path? That would make this plugin unable to do its job. In fact, using a temporary file we created for getBindPath I would think would be better because if the "touch" fails then volume mounting may have succeeded but then this plugin would fail because it won't be able to write files. We'd be able to detect the flaw earlier and give more useful feedback immediately.

[kichik]

Makes sense to change it to a file it creates then, especially since you already had to do that anyway.

[AndrewFarley]

Thanks, I'll clean up the function in my MR then for your review, and maybe it'll help some of these other getBindPath issues (using the different folder may help, not the temp file thing)

[kichik]

@ajshukury same questions go to you. I need more details to be able to help. Please open it as a new ticket and mention me. Also make sure you use the latest version and even master if possible.

[jfaraklit]

Sounds good. I will do that. Thanks @kichik

[akuckreja]

Hey @illagrenan , thanks, this worked for me!!! i suspect this was required for me as my windows password had changed. So when i enabled sharing again, i had to put in my new password.

thanks again

I had the same problem after clean installation of serverless and serverless-python-requirements.

How i fixed this:

1. Open Docker for Windows

2. Go to Shared Drives

3. Make sure `C` is shared. If `C` is already shared, un-share it and share it again

[krashmi]

Hello I am getting an error " Unable to find good bind path format " at the last step "serverless deploy". Using windows container in dockers on windows 10 os. If I switch to Linux container I get a different error " Error -------------------------------------------------- docker: Error response from daemon: invalid mode: /test. See 'docker run --help'. Please help

[moneerrifai]

I wrestled with this for a couple of days. This thread was super helpful. What finally resolved the issue for me was changing the way I was logged in to Docker: I was logged in using my email and password, which it turns out is a valid method to authenticate, but it causes an error when you try to pull down the docker image (which causes the bind path error). Instead, I had to log out and log as docker username/password (instead of docker user email / password) and it worked!

[krashmi]

Finally, my error below was resolved. Unable to find good bind path format " at the last step "serverless deploy". Using windows container in dockers on windows 10 os. If I switch to linux container I get a different error "

I used linux container on windows 10 , In addition to npm install --save serverless-python-requirements i used fix npm i T-Tmnr/serverless-python-requirements#fix-issue-274 and deployment was successful.

[mojimi]

I fixed by typing :

docker login

And logging in, I couldn't login through the docker UI in Windows, it just flashes the inputs red and gives no actual errors or logs, but I believe it is due to proxy

[jorwoods]

I had the same issue. Was caused by docker running windows containers. Switching them to back to linux containers fixed the issue.

[adir1661]

had the same issue... on windows at a linux command line like git bash i used: winpty docker login

[dhulke]

I fixed by turning docker desktop on

[Tsingis]

Getting this error when trying to use serverless framework and deploy AWS lambda via Github action and using windows-latest. This virtual environment is using Docker 19.03.14. The same happens with 20.10.0.

Serverless: Generated requirements from D:\a\telegram-bot\telegram-bot\requirements.txt in D:\a\telegram-bot\telegram-bot\.serverless\requirements.txt...
Serverless: Installing requirements from C:\Users\runneradmin\AppData\Local\UnitedIncome\serverless-python-requirements\Cache\5e61405b67ffec41db1bbd78f432bc4fd4ccdf0af1764200fd7a3859b7126a39_slspyc\requirements.txt ...
Serverless: Docker Image: lambci/lambda:build-python3.8

  Error --------------------------------------------------

  Error: Unable to find good bind path format
      at getBindPath (D:\a\telegram-bot\telegram-bot\node_modules\serverless-python-requirements\lib\docker.js:152:9)
      at installRequirements (D:\a\telegram-bot\telegram-bot\node_modules\serverless-python-requirements\lib\pip.js:198:39)
      at installRequirementsIfNeeded (D:\a\telegram-bot\telegram-bot\node_modules\serverless-python-requirements\lib\pip.js:556:3)
      at ServerlessPythonRequirements.installAllRequirements (D:\a\telegram-bot\telegram-bot\node_modules\serverless-python-requirements\lib\pip.js:635:29)
      at ServerlessPythonRequirements.tryCatcher (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\util.js:16:23)
      at Promise._settlePromiseFromHandler (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\promise.js:547:31)
      at Promise._settlePromise (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\promise.js:604:18)
      at Promise._settlePromise0 (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\promise.js:649:10)
      at Promise._settlePromises (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\promise.js:729:18)
      at _drainQueueStep (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\async.js:93:12)
      at _drainQueue (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\async.js:86:9)
      at Async._drainQueues (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\async.js:102:5)
      at Immediate.Async.drainQueues [as _onImmediate] (D:\a\telegram-bot\telegram-bot\node_modules\bluebird\js\release\async.js:15:14)
      at processImmediate (internal/timers.js:461:21)

EDIT.

Could cache option such as and cacheLocation fix this? Probably need a way to allow file sharing in certain location on the Windows Server as people would do on Docker Desktop.

[movaid7]

I fixed it by installing the latest version of Docker - 20.10.2

[dpeters1]

I found this error also pops up if you're operating in a different docker context. docker context use default resolved it for me.