commercialhaskell / commercialhaskell/stack
Docker startup errors on shared NFS filesystem (WAS: Errors running even "hello world" under Docker with stack)
- 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
Assessment
This issue has not been assessed yet.