Collabora and CAP_MKNOD

🚧 Installation
1

I’ve had NC and Collabora running for a while now, working well. I’ve now wanted to refactor my configs (docker-compose) and one thing that never sat right with me was the offical docs calling for --cap-add MKNOD, aka CAP_MKNOD (man capabilities). This in itself raises red flags (I’ve never had to do this with any other Docker container/service), and this article seems to agree:

Almost no containers ever do this, and even fewer containers should do this.

The most frustrating part is that the requirement for that capability isn’t explained anywhere. It’s just accepted, and it seems like noone has ever asked why this is necessary?

Googling collabora mknod lists many pages, all of which just seem to have copied the

docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=cloud\\.nextcloud\\.com' --restart always --cap-add MKNOD collabora/code

line from the official docs, without mentioning MKNOD otherwise.

I’d be very happy to grant that capability to Collabora if I understood its need better! Can anyone clarify? Thanks!

2

To add further context: MKNOD is part of the default capabilities Docker grants anyway. As it stands, we could simply omit --cap-add mknod entirely. Its only valid use case seems to be to ensure that (apparently dearly needed) capability continues to be granted even if it’s removed from the Docker defaults. That seems unlikely.

The CLI flag in question here is also not part of the offical docs, where it reads:

 docker run -t -d -p 127.0.0.1:9980:9980 -e "domain=" -e "username=admin" -e "password=S3cRet" --restart always collabora/code
1 Like
3

Just learned it the hard way that if you use Podman instead of Docker (which you probably do if you are on Fedora or later RedHat, and i strongly suspect the same goes for Kubernetes), you still need to add the MKNOD capability. Why it is needed is still a big question, though.