On container start, exactly in daemon/start.go, only the hostConfig provided to the API is checked.
If you've previously created a container with a specific hostConfig and then you make changes to the system something could be broken.
I've hit this when unmounting cgroups (memory in my case) but any other hostConfig's field could have this problem I think.
Step to reproduce on an Ubuntu 15.04:

$ docker run -d --memory-swappiness=0 debian:jessie true # memory cgroups is mounted
ba61c3bbe0198643994956aca074976e157ef2521425ac527b1a0b6016e61851
$ sudo umount /sys/fs/cgroup/memory  # umount memory cgroup for instance           
$ docker start ba61c3bbe0198643994956aca074976e157ef2521425ac527b1a0b6016e61851
Error response from daemon: Cannot start container ba61c3bbe0198643994956aca074976e157ef2521425ac527b1a0b6016e61851: [8] System error: no such directory for memory.swappiness.
Error: failed to start containers: [ba61c3bbe0198643994956aca074976e157ef2521425ac527b1a0b6016e61851]

This is happening because the hostConfig in the start API is only checked if it's the one provided in the request and not the actual container's hostConfig (see verifyContainerSettings)
Beaware also that verifyContainerSettings will set for instance MemorySwappiness to nil if it detects the system doesn't have memory cgroup enabled.
Should we check hostConfig before starting container (and show a nicer error and put MemorySwappiness in hostConfig to nil) or this libcontainer error is ok to show if you umount cgroups while running? I have a fix to check container's hostConfig on start also

EDIT: Digging deeper, daemon.sysInfo is only populated on daemon start so even calling verifyContainerSettings in container start still shows the error above

ping @LK4D4 (I've seen libcontainer ignores cgroups path not found error in apply_systemd and try to write the file and erroring out above, wondering if that should be fixed as well)