I'm getting different but possibly related when attempting to reproduce. The error is now occurring during yum -y upgrade, which is failing for several packages. It appears that Apparmor is denying read permission on some files - likely an issue with the Ubuntu docker.io package.

However, I will note that I cannot reproduce the exact error seen here. Running /usr/bin/echo alone does not error, and errors in yum upgrade prevent running the two together. Given this, that issue may be entirely unrelated to the Apparmor denials.

I get the same problem now. I believe the errors during yum -y upgrade will be masking the initial issue I had

The issues in yum upgrade are not fixed by setting the Apparmor profile for Docker to permissive mode. The issue seems to shift to the one documented in https://github.com/dotcloud/docker/issues/5928. In an attempt to fix this, I built the latest version of Docker including the merged fix on Ubuntu and used this version, but the new build fails with the same error.

Given this, I'm unable to reproduce your error. I'll look into filing a bug with the Ubuntu maintainers about this issue, and see if they can put out an updated package with a fix for the issues with yum upgrade.

If you could find the version of Docker you were using when you originally encountered the issue, I can also try downgrading to that version and testing from there.

I've seen the issue with:

Docker version 0.11.1, build fb99f99
Docker version 0.9.1, build 3600720

Matt, this looks more like a docker image problem then a docker-io package problem.  Do we have a place to report fedora image problems?

(In reply to Daniel Walsh from comment #5)
> Matt, this looks more like a docker image problem then a docker-io package
> problem.  Do we have a place to report fedora image problems?

Dan,

There was no good place to report image issues and comments on fedora image page on docker's index didn't trigger any notifications, so I've been redirecting people to our BZ for image problems. 

Also, I'm assigning this to myself (for now) since the unprefixed images are generated by docker/stackbrew from my prefixed images.

sthorger,

Could you try the image lsm5/fedora:21-test ?

I've removed the systemd and iputils packages from this image (not too sure if good or bad idea) as those were giving me aforementioned yum update problems on an ubuntu host.

Relevant tail from run:

Step 2 : RUN mkdir /opt/hello
 ---> Running in 3212d4e00cc3
 ---> 562cf8ffc657
Step 3 : RUN useradd hello -d /opt/hello
 ---> Running in 9ee04671effb
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
 ---> ba179069c24e
Step 4 : RUN chown -R hello:hello /opt/hello
 ---> Running in 3f079fe58813
 ---> 185d77463f12
Step 5 : USER hello
 ---> Running in 4b2cc5edfab7
 ---> a8636cc8f9a1
Step 6 : CMD ["/usr/bin/echo", "Hello world!"]
 ---> Running in 5c288a08fcd6
 ---> 2df863fc6c97
Successfully built 2df863fc6c97
Removing intermediate container 386943a43d39
Removing intermediate container 3212d4e00cc3
Removing intermediate container 9ee04671effb
Removing intermediate container 3f079fe58813
Removing intermediate container 4b2cc5edfab7
Removing intermediate container 5c288a08fcd6

Just tested it out and it works fine here as well

Thanks sthorger.

Question for all: would removing systemd (iputils is probably not too critical) from the fedora image be a good/bad idea? 

This is probably something that needs to go in by end of tomorrow. See Bug 1090890 and https://fedoraproject.org/wiki/Releases/21/Schedule

Looks like this new image had updated systemd and iputils packages which didn't complain during the yum update (as against the old ones), as systemd and iputils still get pulled in during the image creation process, even if I explicitly set the kickstart script to not pull them in.

I just updated the 'fedora' image. Also contains the 21 tag.