commercialhaskell / commercialhaskell/stack

Docker startup errors on shared NFS filesystem (WAS: Errors running even "hello world" under Docker with stack)

Open
#910 3 comments 0 reactions 0 assignees View on GitHub
component: docker
Dominant language
Haskell
Stars
4.1k
Forks
850
Avg merge
10h 37m
Merged PRs (30d)
4

Description

I'm trying to use stack with Docker on an Ubuntu 14.04 system. I've got the `fpco/stack-build:lts-2.22` pulled and can run it fine manually:

```
$ docker run -it fpco/stack-build:lts-2.22
```

But trying to `stack build` using the setup [in this Gist](https://gist.github.com/rrnewton/aa18c86cdb169ce3fca1), gives me the following error:

```
$ stack --version
Version 0.1.3.1, Git revision 908b04205e6f436d4a5f420b1c6c646ed2b804d7
$ stack build
Error response from daemon: Cannot start container c4fe0f7b678f9a885bf966aaf4e505dd5de1bf2d08e73d1d298d415f7ec6d009: stat /nfs/home/rrnewton/build/docker_hello_world/.stack-work/docker/_sandbox/basic_build_lts-2.22_20150811: permission denied
```

I tried deleting the `.stack-work` directory or changing its permissions to no avail. I tried stack master as well as 0.1.3.1 with the following version:

```
Version 0.1.4.0, Git revision 203eb683b79f4dbd6bbed85dcd4fe893978af954 (1738 commits) X86_64
```
### On local storage instead:

This is on a university infrastructure that uses NFS home directories. So of course I tried copying the three files from the Gist (cabal, stack.yaml, main.hs) into a fresh directory in `/tmp`. The funny thing there is that in a clean directory I get a similar error:

```
$ stack build
...
find: `/tmp/docker_hello_world/.stack-work/docker/basic_build_lts-2.22_20150811/.stack/indices/Hackage/packages/x509-validation/1.6.0': Permission denied
find: `/tmp/docker_hello_world/.stack-work/docker/basic_build_lts-2.22_20150811/.stack/indices/Hackage/packages/silently/1.2.5': Permission denied
find: `/tmp/docker_hello_world/.stack-work/docker/basic_build_lts-2.22_20150811/.stack/indices/Hackage/packages/semigroupoids/5.0.0.3': Permission denied
find: `/tmp/docker_hello_world/.stack-work/docker/basic_build_lts-2.22_20150811/.stack/global': Permission denied
find: `/tmp/docker_hello_world/.stack-work/docker/basic_build_lts-2.22_20150811/.stack/build-plan-cache': Permission denied
sed: couldn't open temporary file /tmp/docker_hello_world/.stack-work/docker/basic_build_lts-2.22_20150811/.stack/snapshots/x86_64-linux/lts-2.20/7.8.4.20141229/lib/x86_64-linux-ghc-7.8.4.20141229/QuickCheck-2.7.6/Test/QuickCheck/sed5WkEwz: Permission denied
```

But then the _second_ time I try it it works. That is, I can repeatably run the following sequence as many times as I want:

```
$ rm -rf .stack-work/ .cabal-sandbox/ *~ cabal.sandbox.config
$ stack build

$ stack build

```

Clean the directory, build and error, build and succeed. This works even if changing the command. The very next stack command after cleaning the local directory (e.g. `stack clean`) fails with the permission denied business. I confirmed the above works _even_ if I extend the `rm` line to wipe all of `~/.stack` as well, so hopefully it has nothing to do with the state of that global directory.

I could not reproduce that same quirky behavior with the master (203eb683b79f4dbd6bbed85dcd4fe893978af954) version. It just repeatedly errors with the container problem:

```
$ rm -rf .stack-work/ .cabal-sandbox/ *~ cabal.sandbox.config
$ ~/.local/bin/stack build
Error response from daemon: Cannot start container ffb31e799a06b4e81fb0e44eb75447112fd8bc1e6bfdf7a8a787cceb1a538c8f: stat /nfs/home/rrnewton/.local/bin/stack: permission denied
$ ~/.local/bin/stack build
Error response from daemon: Cannot start container f00942a8a3a83d361a55cd4b3f30c7908ad799761e17ed3c1390f85fcfab04da: stat /nfs/home/rrnewton/.local/bin/stack: permission denied
```

In that one the permissions problem seems more understandable. It's not successfully getting the stack executable itself inside the docker image?

Indeed, if I copy the latest stack version into the current working directory, and then run it with `./stack build`, then I see the same fail-once-with-perm-error-then-succeed behavior as above.

The discrepancy between the two is still odd, however. In the above cases both my stack released and stack head versions were in NFS storage in a home directory. The permission denied error on .local/bin/stack seems to have to do with it not being in the PATH perhaps?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.