I am trying to clear my filesystem cache from inside a docker container, like so:

docker run --rm ubuntu:vivid sh -c "/bin/echo 3 > /proc/sys/vm/drop_caches"

If I run this command I get

sh: 1: cannot create /proc/sys/vm/drop_caches: Read-only file system

which is expected, as I cannot write to /proc from inside the container.

Now when I call

docker run --rm --privileged ubuntu:vivid sh -c "/bin/echo 3 > /proc/sys/vm/drop_caches"

it works, which also makes sense to me, as the --privileged container can do (almost) anything on the host.

My question is: how do I find out, which Linux capability I need to set in the command

docker run --rm --cap-add=??? ubuntu:vivid sh -c "/bin/echo 3 > /proc/sys/vm/drop_caches"

in order to make this work without having to set --privileged?

3 Answers 3


As an addendum to the accpted answer by Gilles: I managed to achieve my goal of writing to /proc/sys/vm/drop_caches (or to /proc in general, to be precise) in a much easier way when working with docker:

docker run -ti --rm -v /proc:/writable_proc ubuntu:vivid bash
# echo 3 > /writable_proc/sys/vm/drop_caches

That does it for my purpose.

Thank you very much for your helpful answer!

  • It seems they conflict? It suggests Gile's answer doesn't apply, i.e. docker isn't using user namespaces here. The extra bind mount should still be subject to the problem Giles mentioned, if Docker was using user namespaces. Docker doesn't add any user translation layer for mounts which you bind into the container.
    – sourcejedi
    Mar 23, 2018 at 8:43

The proc filesystem doesn't support capabilities, ACL, or even changing basic permissions with chmod. Unix permissions determine whether the calling process gets access. Thus only root can write that file. With user namespaces, that's the global root (the one in the original namespace); root in a container doesn't get to change sysctl settings.

As far as I know, the only solution to change a sysctl setting from inside a non-privileged namespace is to arrange a communication channel with the outside (e.g. a socket or pipe), and have the listening process run as root outside the container.

  • I put in another answer that solves my problem. Your reply however is absolutely correct for what I asked, so I'll make it the accepted answer. Thanks. Jun 13, 2015 at 12:33

I just tested the following:

docker run -ti --rm -v /proc:/writable_proc rhel bash
echo 3 > /writable_proc/sys/vm/drop_caches

And, it failed:

bash: /writable_proc/sys/vm/drop_caches: Permission denied

I run it with privileged:

docker run -ti --rm --privileged -v /proc:/writable_proc rhel bash
echo 3 > /writable_proc/sys/vm/drop_caches

And, everything worked, so I am pretty sure that somehow things worked for Gilles because his daemon or cli is configured to use privileged without knowing it:

  • I guess it might be because you have SELinux (or AppArmor?) in your docker install.
    – sourcejedi
    Mar 14, 2018 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.