MacOS Docker deploy use /private/var instead of /var

[ttonyh]

In MacOS, please consider changing the Docker command to use /private instead of /var. "/private/var" is an alias to "/var" and is by default exported to Docker i MacOS. To get node-lambda to work, I had to remove the default value of "/private" and replace it with "/var/folders". This is because Docker (8.x) won't let you have both because they are considered the same.

Solution: Since the tmp folder path is probably auto generated, you might need to just prepend "/private" to the path, if the OS is MacOS.

Here's more info on the subject:
https://stackoverflow.com/questions/45122459/docker-mounts-denied-the-paths-are-not-shared-from-os-x-and-are-not-known

[DeviaVir]

I'm not sure what you are referring to here. The only thing I could find was https://github.com/motdotla/node-lambda/blob/master/lib/main.js#L346 - assuming you supplied to codeDirectory I don't see a mac OS specific problem here.

[akofman]

Actually, from OSX, depending on your node version os.tmpdir() will return /var/folders/... (which is a symlink to /private/var/folders/...) or /private/var/folders/.... (see nodejs/node#11422)

So in your Docker config you have to add both paths as shared files. As @ttonyh said, this also depends on the version of your Docker Application for OSX (and not the version of the Docker engine), and fortunately the last versions permit to add both paths, I tested it from the version 2.0.0.0-beta1-mac75 and it's ok.

To completely fix this, maybe you could use ${fs.realpathSync(codeDirectory)} here : https://github.com/motdotla/node-lambda/blob/master/lib/main.js#L346. This will ensure to always return the real path and not a symlink.

[Ethaan]

i'm getting a similar issue, see below.

$ node-lambda package --dockerImage lambci/lambda:nodejs6.10 -A pkg --handler index.handler --functionName ImageResizer
=> Moving files to temporary directory
=> Running npm install --production
(node:3262) UnhandledPromiseRejectionWarning: Error: Command failed: docker run --rm -v /private/var/folders/w4/5bbxj8rx7d90pd_t08pqp__40000gn/T/ImageResizer-lambda:/var/task -w /var/task lambci/lambda:nodejs6.10 npm -s install --production
START RequestId: 7bd8de15-49e0-16b2-f1ad-d61fd27fd00f Version: $LATEST
Unable to parse input as json: Unexpected token s in JSON at position 1: SyntaxError
    at Object.parse (native)
END RequestId: 7bd8de15-49e0-16b2-f1ad-d61fd27fd00f
REPORT RequestId: 7bd8de15-49e0-16b2-f1ad-d61fd27fd00f  Duration: 4.98 ms       Billed Duration: 100 ms Memory Size: 1536 MB    Max Memory Used: 28 MB

    at ChildProcess.exithandler (child_process.js:294:12)
    at ChildProcess.emit (events.js:188:13)
    at ChildProcess.EventEmitter.emit (domain.js:441:20)
    at maybeClose (internal/child_process.js:978:16)
    at Socket.stream.socket.on (internal/child_process.js:395:11)
    at Socket.emit (events.js:188:13)
    at Socket.EventEmitter.emit (domain.js:441:20)
    at Pipe._handle.close (net.js:610:12)
    at Pipe.<anonymous> (/Users/Ethaan/.nvm/versions/node/v11.6.0/lib/node_modules/node-lambda/node_modules/async-listener/glue.js:188:31)
(node:3262) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:3262) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[dereksorensen]

@Ethaan I ran into this too. Turns out you have to use the build specific docker image from lambci: lambci/lambda:build-nodejs<version>. The other one is meant for running your lambda and accepts a json as the docker command.