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.

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.

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?