Apparmor "no such file or directory"

[dsyer]

$ fig up
Recreating <xxx>...
Cannot start container a3e4fd060d01a12ab7f810a91a341a44a5f9414fb814a3d29d8229bbb4dd3004: set apparmor profile docker-default: no such file or directory

This change to docker claims to have fixed the problem: moby/moby#6180, but it's still failing for me.

$ docker -v
Docker version 1.1.2, build d84a070
$ fig --version
fig 0.5.2

[aanand]

Does the same thing happen if you try to docker start the relevant container?

[dsyer]

No, I can start the container normally with docker just fine.

[dsyer]

Actually, scratch that last reply. I can use docker to start the same base image, but I can't start the image created by fig:

$ docker start ec0865c555f472166af4ad0a7a934ca4a983b4ac5a7a85601fa02ffd30efc590
Error response from daemon: Cannot start container ec0865c555f472166af4ad0a7a934ca4a983b4ac5a7a85601fa02ffd30efc590: set apparmor profile docker-default: no such file or directory
2014/08/13 08:41:38 Error: failed to start one or more containers

[dnephin]

I notice that the original example says it's recreating. What happens if you fig rm --force -v (this will remove volumes), and then do a fig up. If that works, it maybe be related to #328

[dsyer]

Thanks. But no change.

$ fig rm --force -v
No stopped containers
$ fig up
Creating scripts_eureka_1...
Cannot start container 37cd353733ead3a7e89ca1c74200e30152beed171f51995b25f9f629ef919893: set apparmor profile docker-default: no such file or directory

Docker was in a bit of a mess when I started this (confusion about versions and Ubuntu packages). Is there something else I can do to create a clean slate?

[dsyer]

More digging here reveals that it breaks in this way if I declare volumes, and not if I don't. I see this in the fig.yml docs: "Mapping local volumes is currently unsupported on boot2docker." But I have no idea what that means. The workaround suggested is to "use docker-osx", but I'm on an Ubuntu host, so that doesn't help. If I can't declare local volumes it's kind of bust.

[dnephin]

Volumes should work from a linux host, that warning is just for osx users I think (might need some clarification, it seems to assume that most people are on osx).

It may be related to the base image you're using? Can you reproduce with ubuntu:14.04 and a volume?

[dsyer]

Yes, that is still broken. Here's the fig.yml:

test:
  image: ubuntu:14.04
  volumes:
    /root:.
  command: echo "Hello World"

[dsyer]

Aha. User error: the volumes are an array (even if single valued). That fig.yml is still illegal for some reason when I fix it (I can't bind to "."), but it's a different error at least. Why can't I bind to "."?

[dnephin]

I believe they need to be absolute paths (https://docs.docker.com/userguide/dockervolumes/)

[dsyer]

OK, I guess I get work around that using "${PWD}". IMO part of the value of fig should be to avoid that kind of limitation invisibly. Now let's see if I can do something really useful with it...

As far as the original issue goes, maybe fig should validate its YAML better to avoid cryptic errors from a different layer?

[dnephin]

Definitely #129 is the issue for that.

[aanand]

Mounting to a relative path inside the container feels really weird to me. What were you trying to do?

[dsyer]

The opposite (duh!). Off by one error means you mount in the wrong direction. Sorry for the noise (it was unrelated to the original problem anyway).

[dsyer]

#129 seems like the right place to discuss the validation issue