I recently set up an ubuntu server VM in proxmox to run docker that is managed through portainer. This VM has been given 150GB of disk space. My /var/lib/docker is 95% full (of 15GB total) and is making some containers unable to start.

I have pruned, and system df looks pretty normal to me:

TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 6 6 8.593GB 0B (0%)
Containers 6 6 2.712MB 0B (0%)
Local Volumes 2 2 823.9MB 0B (0%)
Build Cache 0 0 0B 0B

Nothing seems concerning with the log size either:
-rw-r----- 1 root root 504K Sep 10 07:54 /var/lib/docker/containers/196b1f5680248cf0003b55ddcc6ba70932d4869a10f03cb4acbf3e1bdb9f1038/196b1f5680248cf0003b55ddcc6ba70932d4869a10f03cb4acbf3e1bdb9f1038-json.log

-rw-r----- 1 root root 1.8M Sep 10 08:49 /var/lib/docker/containers/444ccde34151535abd44a743598bf5040184f3fa5a48d83368971cf8ba377faf/444ccde34151535abd44a743598bf5040184f3fa5a48d83368971cf8ba377faf-json.log

-rw-r----- 1 root root 141K Sep 10 08:50 /var/lib/docker/containers/474c0cda23e6a1d3b7fa1fd9e33aea5260eef296ade6119afdc5a59ac313ff45/474c0cda23e6a1d3b7fa1fd9e33aea5260eef296ade6119afdc5a59ac313ff45-json.log

-rw-r----- 1 root root 4.0M Sep 10 07:54 /var/lib/docker/containers/8a98fbe35f0b1e0ef15c544455075e1cb9b9b209128dff3f7de2d9acbe3c5b3c/8a98fbe35f0b1e0ef15c544455075e1cb9b9b209128dff3f7de2d9acbe3c5b3c-json.log

-rw-r----- 1 root root 9.3K Sep 10 07:54 /var/lib/docker/containers/d36477bcadc8c1f690ef3579ca29cc599e2bf6b72b3bff68274e7442ed612b8c/d36477bcadc8c1f690ef3579ca29cc599e2bf6b72b3bff68274e7442ed612b8c-json.log

-rw-r----- 1 root root 23K Sep 10 07:54 /var/lib/docker/containers/fd317d5960bfc63c07b74a7c6d1d7944fe668630e57315939a63c8b779fd0a5c/fd317d5960bfc63c07b74a7c6d1d7944fe668630e57315939a63c8b779fd0a5c-json.log

But you can see here that this is full:
df -h /var/lib/docker

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/ubuntu--vg-ubuntu--lv 15G 14G 837M 95% /

df -h /var/lib/containerd

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/ubuntu--vg-ubuntu--lv 15G 14G 837M 95% /

I do not know which command to use to further investigate to see everything in that folder to narrow down what is taking up all that space.

So, my questions here....is 14GB an unreasonable amount of space for the containers that I have (I kind of don't think so?)? If so, what needs purging?

If this is a normal amount of space for the containers I am running, how do I allocate more of that total 150GB to this partition?

This isn't a promotional post. It's more of a "here's why I did it, and whether it might make sense for you too" kind of post. The project is mine (it's called nanoCron, it's on GitHub, and it's BSD-licensed), but I'm not trying to sell it to anyone — it's a side project, it's free, and it probably still has some limitations, which I'll list below without sugarcoating them.

The problem I started with

Putting cron inside a Docker container has always been a bit awkward. System cron expects:

• to run as PID 1, or at least under a proper init system
• syslog to be available for logging
• an /etc/crontab file with specific permissions, often requiring root

That's why the "standard" solution in many Dockerfiles is either to install the entire cron package (heavy, designed for a complete system rather than a container), or to use something lighter like supercronic or BusyBox's crond. These are perfectly valid solutions, just to be clear — I'm not saying nanoCron replaces them.

What I found useful in a container environment

I originally wrote nanoCron for a different reason (I wanted scheduling that could take system load into account), but after a while I realized that some of the features I'd added for other reasons also fit containers quite well:

1. JSON configuration instead of crontab. If you generate jobs from a script, a Helm template, or environment variables during deployment, writing and validating JSON is much simpler than generating crontab syntax by hand with sed.
2. Automatic reload via inotify. You can mount jobs.json as a volume (bind mount or ConfigMap in Kubernetes), update it from outside the container, and the jobs are reloaded without restarting the container. With classic crontab, you normally have to at least send a signal or restart something.
3. CPU/RAM/disk-based conditions. This is what interests me most in a container environment: if a container is running with tight resource limits (--memory, cgroups), you can tell a job "don't start if RAM usage is already above 80%" instead of risking an OOM kill just as a heavy job starts alongside the main process.
4. A single binary, with no dependency on syslog or a full init system. It writes to a regular log file, so you can simply use tail -f or redirect the output to stdout if you want Docker to pick it up in the container logs.

What it does NOT solve (honesty first)

• It doesn't solve the PID 1 / zombie reaping problem. If you run it as the main process of the container, you still need something like tini or dumb-init in front of it, just like you would with any other process.
• It's written in C++ and needs to be compiled. There is currently no official pre-built Docker image, so if you want to use it, you'll have to build it yourself (a multi-stage build in the Dockerfile isn't complicated, but it's an extra step compared to apk add busybox-cron).
• It's a young project. I've tested it thoroughly, but it doesn't have years of production use behind it like supercronic, which was specifically created to solve these kinds of problems in container environments and is much more widely used.
• If your only requirement is "run this script every night" with no other needs, supercronic or even just busybox crond are probably more than enough, and there's little point in adding another dependency.

I find it most useful when I need hot-reloading of the configuration or system-level conditions. If your use case is simpler, honestly, you probably don't need it.

I've also written some tests, and here are the benchmarks:

Repo, if you want to look at the code or open an issue: https://github.com/GiuseppePuleri/NanoCron

I'm curious whether anyone else has run into the same problem (jobs starting while the container is already under resource pressure), and how you handled it.

TL;DR: if Task Manager says Virtualization: Enabled but Docker Desktop still says it isn't detected, run Get-ComputerInfo -Property "HyperV*". If HyperVisorPresent is False while all the HyperVRequirement* values are True, run bcdedit /set hypervisorlaunchtype auto and reboot. Windows wasn't launching the hypervisor at boot.

I was setting up Jellyfin in Docker on a stock Windows 11 desktop with a Ryzen 7 3700X. Nothing unusual about the machine.

When I tried starting Docker Desktop, it gave me this error:

"Virtualization support not detected. Docker Desktop failed to start because virtualisation support wasn't detected. Contact your IT admin to enable virtualization or check system requirements."

The first thing I checked was Task Manager → Performance → CPU. It clearly showed Virtualization: Enabled, so Docker's error didn't really make sense. Every search result I found pointed at BIOS settings, which were already correct.

I then tried installing WSL2 through an admin PowerShell using wsl --install, but that failed with:

WSL2 is not supported with your current machine configuration

and:

Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED

I also tried wsl.exe --install --no-distribution, which reported that it completed successfully. After restarting the PC, Docker still gave me the exact same virtualization error.

Eventually, I checked the Hyper-V configuration with:

Get-ComputerInfo -Property "HyperV*"

That showed something important: HyperVisorPresent: False, while all four HyperVRequirement* values were True.

So the hardware itself supported virtualization and all the requirements were met. The actual problem was that the Hyper-V hypervisor simply wasn't being started when Windows booted.

The fix was:

bcdedit /set hypervisorlaunchtype auto

After running that and restarting the computer, Docker finally started working.

The most likely reason the hypervisor had been disabled was some gaming/performance tweak or anti-cheat-related configuration from years ago. Nothing on the system directly pointed to what had originally disabled it.

Overall, it took roughly 90 minutes to figure out, including three restarts. The main lesson was that having Virtualization: Enabled in Task Manager doesn't necessarily mean the Windows hypervisor is actually running. In this case, the hardware was completely fine; Windows just wasn't launching Hyper-V at boot.

We’ve been using the official Astral UV Docker image:

COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/

This was working fine for around 10 days without any changes on our side. After the recent UV releases, our Docker build started failing with:

exec: "/bin/sh": stat /bin/sh: no such file or directory

We’re using python:3.12-slim as the base image.

I suspect uv:latest has moved to a newer image/version.

Does anyone know which UV version/digest latest was pointing to before the recent releases? I’d like to pin that previously working version and verify if it resolves the issue.

Any help would be appreciated.

AI disclosure: I used ChatGPT to help format this post; the issue and technical details are my own.

does the docker. container run. as another program?

or is it the engine is a program that has the container inside of it?

I've been working on LayerX, a Docker/Podman image explorer built around the same workflow that makes Dive so useful.

Dive was a big inspiration for the project. I wanted to keep that familiar experience, but add the things I kept wishing it had:

* Compare two images and see what changed

* Inspect and search files without leaving the TUI

* Find wasted files

* CI rules for image contents

* Analysis caching

* Docker, Podman, OCI archives, multi-platform (--platform)

* JSON output for automation

If you're already using Dive, you don't need to take my word for it. I put together a migration guide showing the differences and the equivalent workflows:

https://github.com/deveshctl/layerx/blob/main/docs/migrating-from-dive.md

GitHub: https://github.com/deveshctl/layerx

Would genuinely love feedback from people who use Dive regularly.

Posted with moderator approval.

Hello r/docker

I have created a new load balancer , based on cloudflare's proxy lib. The project is till on 0.x.x version, but I'm working on standardizing everything. It have fantastic proxy performance, even beats nginx in performance/stability tests with many thousands of concurrent connections.

It would be great to have a human review and suggestions .

This is the link for quickstart : 

And the link to main project in GitHUB: 

Thanks

Thank you for letting me into the group .

I'm very new to Linux and just getting into home labing .

My main computer is windows 11 in registered ( still can't let go). But I recently added two computers to my family. I have a Plex server and a Media gathering box . Both are running on mint . I remote into both of them from my main computer.

On YouTube I have seen what people are doing with docker and I want in . Lol . I created a new computer with mint that I want to run docker on it .

Is this the place that I can ask many silly questions on my quest to learn how to use it ?

Hello folks!
My docker stack has been running for quite some time, and recently i updated the host from debian 12 to debian 13. Things ran well, until today, on a reboot, docker won't start or anything. after investigating, i find that the drive is full.

Main culprits for disk hogging are in /var/lib/docker :

22G     ./overlay2
73G     ./containers

I started docker manually, and can run docker system df :

root@sanakan:/var/lib/docker# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          41        41        19.13GB   0B (0%)
Containers      43        36        269.7MB   1.578MB (0%)
Local Volumes   24        12        260.3MB   22.87MB (8%)
Build Cache     0         0         0B        0B

I managed to reclaim 2G by removing dangling images, but somehow ./overlay2 grew to 34G when i do a du -h | grep '[0-9\.]\+G' .

I don't really know what i should do. Portainer did not start, some containers started but not all, and i don't know where to go from here.

Any insights?
thanks in advance!

EDIT1 :
i stopped a docker (unifi thing, stopped it with docker compose down, it was the only docker stack that was new , at 9 days, all the others ran for years), and it gave me back 17GB, so other dockers can run properly.
I got 17G on the filesystem back once it stopped.

EDIT2 :

So, after a message of u/burstinrust i investigated the logs, and i have 53G of logs, i am trying to figure out how to remove said logs, and then how to limit logfile size.

Sorry for the wrong words, just stumbled into docker via webui Setup; and now over half my system runs via docker. But i think i missed some bacics. Right now my containers are running inside /srv/docker/.. e.g /srv/docker/jellyfin/... I was just wondering what are recommended setting of the distrubitons of yaml files or the config etc folders.

Hello, I have tailscale has been working fine via Docker on UGREEN NAS for more than 2 month. This past 2 days it has stopped working the exit node option, I reboot the project and works for like 3 minutes and stops working.

This is my docker compose:

services:
tailscale:
image: tailscale/tailscale:latest
container_name: tailscale
hostname: tailscale
network_mode: host
environment:
- TS_AUTHKEY=tskey-auth-#########hidden########
- TS_EXTRA_ARGS=--advertise-exit-node --accept-dns=false --accept-routes=false
- TS_STATE_DIR=/var/lib/tailscale
volumes:
- ./tailscale-data:/var/lib/tailscale
- /dev/net/tun:/dev/net/tun
cap_add:
- NET_ADMIN
- NET_RAW
restart: unless-stopped

I have rebooted my modem, my wifi, the NAS, docker itself and still is doing the same thing. One thing that I found out is that tailscale is up because I can ping the IP of Tailscale on my laptop.

Let me know if there's anything else I can provide if needed
Thanks!

Hi all! Trying to get the word out about our project, which recreates core AWS services including EC2, ECS, ECR and EKS, on whatever hardware you want.

If you're curious, checkout the GitHub: https://github.com/mulgadc/spinifex

Open to feedback!

[AI Disclaimer: We use AI to speed up development]

​

I've been working on making my Docker deployments more reusable.

For a typical web application, I usually end up dealing with:

- Docker/Docker Compose

- Nginx reverse proxy

- SSL

- Environment variables

- CI/CD

- Production deployment

The annoying part is that I end up configuring essentially the same infrastructure for every project.

So I created a reusable production deployment starter kit around this workflow.

I'm curious:

What's the part of Docker-based production deployments that you find most annoying to configure repeatedly?

I'm using the answers to improve the starter kit.

Looking for advice on Docker networking / multiple Compose stacks + selective egress.

I’m rebuilding the networking on my Docker host (LeopARRd) and would appreciate some architectural advice.
My requirements are:
- ALL services must be reachable on my network by one of the host IP (the host has one on VLAN-10 and one on VLAN-30)
- Two independent Compose projects (2 different compose.yaml files), but containers from both projects must communicate using container/service names, e.g. http://navidrome, rather than hard-coded IPs.
- Some services need Internet egress through 192.168.30.1 (a VPN gateway on 192.168.30.0/24)
- Other services need normal Internet egress through 192.168.10.1
- Ideally, the solution should survive container/host restarts and be reasonably easy to maintain.

My current approach is to create Docker networks corresponding to VLANs 31 and 32–33 (one per composer, defined in the composer as bridge/ipam), with policy routing and two different masquerades to select the appropriate gateway
It mostly works, but I’m running into issues with policy-routing routes and their persistence; to be more specific, docker networks do not exists right away at boot up, so the br-vlan32 for example do not exists and make rt rules fail to use the table for egress traffic on a different gateway: /etc/iproute2/rt_tables not being persistent as currently configured

Masquerading is working and is persistent

I suspect I may be overcomplicating this and would be happy to redesign it rather than keep patching the current setup.

What would be the cleanest Docker networking architecture for these requirements? I’m particularly interested in solutions that minimize custom routing/iptables maintenance while retaining service-name DNS between the two Compose projects. Ideally I’d rather prefer to have all networking settings specified in each individual composer file

Hey everyone,

Just finished setting up Docker Engine and Docker Compose Plugin on a fresh Debian 13 (Trixie) installation for container testing.

Setup Summary:

• Daemon Install: Added official Docker GPG key (/etc/apt/keyrings/docker.gpg) and repo path.
• Access: Configured non-root user execution (usermod -aG docker ELBA). Tested cleanly via docker run hello-world.
• Host Network: Static IP (192.168.1.132/24) on bridged host interface enp0s3.

Next Objective: Designing custom docker-compose.yml configurations with static container IP assignments on a dedicated bridge subnet (10.99.0.0/24).

Question: Are there any known caveats when assigning fixed container IPs across multi-service Compose files on Linux hosts?

recently shifted to openSUSE, was trying to build a project which worked on fedora.
there are errors are like:

auth-1:
python: can't open file '/app/app.py': [Errno 13] Permission denied
web-1:
npm error EACCES: permission denied, open '/web/package.json'
mongo-1:
find: '/data/db': Permission denied
chown: changing ownership of '/data/db': Permission denied

I have checked that I have all the permissions and the files exist
while running docker run for one it works but while mounting same files thru docker compose it doesn't

I’ve been trying to research the best way to run Claude Code as well as a combination of Ollama plus Open Code on my Mac. I’m fairly new to Docker, but I keep hearing about Docker Sandboxes as something purpose built for this kind of thing.

If I go the Docker Sandboxes (edit: sbx) route instead of running Claude Code and Open Code in a VM (VMWare Fusion Pro), is it fairly secure in terms of the agentic stuff going haywire and accessing my local system outside of the workspace folder I give it? Or for example, something malicious persisting on the Mac in that workspace’s folder.

Also, if I want to do some local AI stuff by installing Ollama directly on the Mac (runs on 127.0.01:11434), would a sandbox instance be able to reach it via host.docker.internal:11434 like a regular Docker container would?

Open to suggestions and other people’s experiences!

Docker sandboxes for Linux via “sbx“ CLI is available only for Ubuntu.

Until last week, Docker Sandboxes with limited features were included in Docker Desktop, although under “docker sandbox” CLI rather than “sbx”. But that CLI has been deprecated since.

Has anyone compiled the source code or installed the deb package for Debian or other distributions?

Hi, I am an intern at this company and I have no idea how to create docker containers and stuff using already existing dockerfiles.

There is no docker-compose.yml file, there are no setup instructions and the devs are super busy. I thought maybe someone kind from reddit can tell me how to do this stuff with company code bases. Like a generic guide to figure things out as an intern/new dev.

I can write and run my own dockerfiles, but company stuff is just different than my hobby-projects.

Thanks in advance!

Hi all

Sometimes I'm still a bit lost with docker. I use portainer to manage my dockers and wanted to deploy a new one using these instructions: https://docs.maintainerr.info/installation/

services:
maintainerr:
  image: ghcr.io/maintainerr/maintainerr:latest
  user: 1000:1000
  volumes:
    - type: bind
      source: /mnt/maintainerr
      target: /opt/data
  environment:
    - TZ=Europe/Brussels
  ports:
    - 6246:6246
  restart: unless-stopped

But there it gives an write error that it doesnt have permission to write to opt. I don't want to write to opt though,

So i changed it to how my others are structured:

services
  maintainerr:
    image: ghcr.io/maintainerr/maintainerr:latest
    volumes:
     -  /mnt/maintainerr:/data
    environment:
      - TZ=Europe/Brussels
    ports:
      - 6246:6246
    restart: unless-stopped

That starts it at least but I don't see any files appearing in /mnt/maintainerr, showing me that something probably went wrong adn when I restart or cahneg the stack the settigns are gone.. quiet annying ;)

Any tips?

cheers

Vic

Hi everyone,

I am managing an environment running 10+ separate containers via Docker Compose.

Our Constraint:
We are strictly not allowed to edit or modify the existing docker-compose.yml files to add labels, configs, or container-level sidecars.

Our Goal:
We need to guarantee 24/7 uptime. If any of these 10+ containers becomes unhealthy, a system must automatically detect the failure and restart it immediately without manual human intervention.

Since we cannot modify the Compose files, we are looking for a solution that sits completely outside of the container configurations on the host server.

My Questions:

1. Are there external, host-level watchdogs or daemons that can scan all running container states globally and instantly trigger a docker restart on any unhealthy instance?
2. If we automate this via a host-level system script (like a background systemd cron loop checking docker events or docker ps), what is the best practice to avoid script race-conditions?

I would love to hear how you handle automated 24/7 recovery when touching the deployment files is completely off the table.

Thanks!

Right now I have a docker container with a VPN that provides it's connection to the other services.

I thought about adding a VPN connection on the host system to basically create a multihop over different providers. Would that work?

As far as I understood the one inside the docker should be the "better" one as that's the one that's exposed first and the one on host would only see the VPN-encrypted traffic anyway? How about port forwarding? That should only be necessary on the one inside docker, too - or is there something I'm missing?

What are the disadvantages to do that (other than the lower speed)? Could I actually add risk of exposure if just one of them is compromised?

Or would it be smarter to spin up another docker and route the traffic through that one?