Docker Friction Deep-Dive — Permissions, WSL2, and Gateway Access

Docker is still widely used for packaging and running software, but a new analysis from Kilo argues that it creates recurring friction for operators in three predictable places: file permissions, WSL2 UID/GID mismatches, and access to services from outside the container network. The piece frames these as symptoms of a deeper issue, not isolated bugs, and says many community discussions now point to Docker being the wrong abstraction for a large share of real-world admin work.

The first problem is file permissions. Docker containers often run processes as a different user than the host system expects, so files created inside a container can end up owned by root or by an unexpected numeric user ID. That becomes painful when a mounted volume needs to be edited, backed up, or cleaned up on the host side. In practical terms, the same file can look normal inside the container and awkward or inaccessible on the host, which is why operators keep running into permission fixes, ownership changes, and permission bits that do not behave the way they expect.

The second issue comes up most often in Windows environments that use WSL2, the Windows Subsystem for Linux 2. WSL2 lets people run a Linux environment on Windows, and Docker on top of that adds another layer of identity mapping between the Windows host, the WSL2 distribution, and the container itself. The analysis says UID and GID conflicts, meaning mismatches between the numeric user and group IDs used by Linux systems, can create confusing access problems when files are shared across those layers. What should be a simple bind mount can turn into a mess of ownership changes and permission workarounds.

The third pain point is gateway access, which is basically the problem of reaching a service running in a container from outside that container or from another machine on the network. Docker’s default networking model makes local container communication simple enough, but it can be less straightforward when the service needs to be exposed through a host network, a reverse proxy, or a gateway device. The article treats this as another example of Docker optimizing for an internal model of application isolation, while operators often need something closer to direct host-level control.

Taken together, these issues support the broader argument in the Kilo analysis that Docker often makes sense for developers packaging applications, but is less comfortable for operators who care about file ownership, persistent storage, and network reachability. That tension is not new. It has been discussed for years in system administration communities, especially among people who run infrastructure on bare metal, virtual machines, or self-hosted platforms where the host environment matters just as much as the containerized app.

The analysis also reflects a practical shift in how some teams think about container tooling. Instead of treating Docker as the default abstraction for every workload, operators are increasingly comparing it with alternatives that fit their environment more naturally. That includes runtime setups that are easier to integrate with host permissions and network policy, as well as deployment models that do not introduce an extra translation layer between the operator and the service.

Kilo’s framing is blunt, but the underlying complaint is familiar to anyone who has tried to make containers behave like ordinary server processes. A container may be isolated by design, yet the real work of administration still happens at the boundaries, where the host filesystem, user IDs, and network path all have to line up, and that is where Docker most often shows its seams.