Docker Compose: /mnt/sdb is always full

I’m working on a new docker-compose setup for Magento 2.4.2-p1.

I started to have issues with MySQL container running out of disk space.

There is a ton of space on my hard drive and on the Ubuntu (WSL2 on Windows 10).

Here is the output of MySQL container:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         251G   23G  216G  10% /
tmpfs            64M     0   64M   0% /dev
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
shm             4.0G     0  4.0G   0% /dev/shm
/dev/sdd        251G   23G  216G  10% /etc/hosts
/dev/sdb        251G  238G  1.2G 100% /etc/mysql/conf.d/my.cnf
tmpfs           7.9G     0  7.9G   0% /proc/acpi
tmpfs           7.9G     0  7.9G   0% /sys/firmware

/mnt/sdb always full

So this must be something within Docker that is causing this. I noticed when I mount /var/www/php/ folder within docker-compose.yml to the mysql-74 container, it assigns it to /mnt/sdb. And every time /mnt/sdb is full!

mysql-74 container

Here is the output with the /var/www/php mounted on mysql-74 container:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         251G   23G  216G  10% /
tmpfs            64M     0   64M   0% /dev
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
shm             4.0G     0  4.0G   0% /dev/shm
/dev/sdb        251G  238G  1.2G 100% /var/www/php
/dev/sdd        251G   23G  216G  10% /etc/hosts
tmpfs           7.9G     0  7.9G   0% /proc/acpi
tmpfs           7.9G     0  7.9G   0% /sys/firmware

php-74 container

If I look inside php-74 container there is a ton of space on it:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         251G   23G  216G  10% /
tmpfs            64M     0   64M   0% /dev
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
shm              64M     0   64M   0% /dev/shm
/dev/sdd        251G   23G  216G  10% /etc/hosts
tmpfs           7.9G     0  7.9G   0% /proc/acpi
tmpfs           7.9G     0  7.9G   0% /sys/firmware

Why is this happening? Is there another way to mount folder from another container? I just need it for ease of dumping / importing databases from my local folder.

docker-compose.yml

Here is my full docker-compose.yml file:

version: '3'

# Services
services:  
  # PHP Service
  php-74:
    build: ./.docker/php
    container_name: php-74
    #restart: always
    working_dir: /var/www/php
    environment:
      - COMPOSER_MEMORY_LIMIT=-1
    volumes:
      - ./src:/var/www/php
      - ./.ssh:/root/.ssh
    links:
      - mysql-74
      - redis-74
    depends_on:
      - mysql-74
    networks:
      - app-network-74

  # MySQL Service
  mysql-74:    
    shm_size: '4G'
    image: mysql:8.0.25
    container_name: mysql-74
    #restart: always
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: magento
    volumes:
      - ./.docker/mysql/my.cnf:/etc/mysql/conf.d/my.cnf:ro
      #- mysqldata:/var/lib/mysqlmys
      #- ./assets:/var/www/php
      #- ./assets:/home/magento
    ports:
      - "3306:3306"
    networks:
      - app-network-74

  # PhpMyAdmin Service
  phpmyadmin-74:
    image: phpmyadmin/phpmyadmin:5-fpm
    container_name: phpmyadmin-74
    #restart: always
    environment:
      PMA_HOST: mysql-74
    volumes:
      - phpmyadmindata:/usr/src/phpmyadmin
    links:
      - mysql-74:db
    depends_on:
      - mysql-74
    networks:
      - app-network-74

  redis-74:
    image: redis:6
    #restart: always
    container_name: redis-74
    volumes:
      - redis-data:/data
    networks:
      - app-network-74

  # Nginx Service
  nginx-74:
    image: nginx:1.18
    container_name: nginx-74
    #restart: always
    ports:
      - 80:80
    volumes:
      - ./src:/var/www/php:ro
      - ./.docker/nginx/conf.d:/etc/nginx/conf.d:ro
      - phpmyadmindata:/usr/src/phpmyadmin
    depends_on:
      - php-74
      - phpmyadmin-74
    networks:
      - app-network-74

  elasticsearch-74:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.9.3
    container_name: elasticsearch-74
    ports:
      - "9200:9200"
      - "9300:9300"
    networks:
      - app-network-74
    environment:
      - "discovery.type=single-node"
    

  rabbitmq-74:
    image: rabbitmq:3.8-management
    container_name: rabbitmq-74
    ports:
      - "15672:15672"
      - "5672:5672"
    volumes:
      - rabbitmqdata:/var/lib/rabbitmq
    networks:
        - app-network-74    

# Volumes
volumes:
  mysqldata:
  phpmyadmindata:
  redis-data:
    external: false
  elasticsearch:
  rabbitmqdata:

#Docker Networks
networks:
  app-network-74:
    driver: bridge

UPDATE:

Output of df on Ubuntu WSL2:

[email protected]:~/php74$ df -m
Filesystem     1M-blocks   Used Available Use% Mounted on
/dev/sdb          257007 242729      1155 100% /
tmpfs               8006    401      7606   6% /mnt/wsl
tools             976116 470182    505935  49% /init
none                8004      0      8004   0% /dev
none                8006      1      8006   1% /run
none                8006      0      8006   0% /run/lock
none                8006      0      8006   0% /run/shm
none                8006      0      8006   0% /run/user
tmpfs               8006      0      8006   0% /sys/fs/cgroup
C:               976116 470182    505935  49% /mnt/c
D:               476295   1535    474761   1% /mnt/d
/dev/sdd          257007  23347    220536  10% /mnt/wsl/docker-desktop-data/isocache
none                8006      1      8006   1% /mnt/wsl/docker-desktop/shared-sockets/host-services
/dev/sdc          257007    132    243752   1% /mnt/wsl/docker-desktop/docker-desktop-proxy
/dev/loop0           396    396         0 100% /mnt/wsl/docker-desktop/cli-tools

UPDATE: Looks like I found the issue.

Magento 2.4.2-p1 has issues with CSP module dumping a lot of data into cache. Once you disable the CSP module the issue with cache overfilling (be it Redis or File cache) stops.

php bin/magento module:disable Magento_Csp

Answer

Those are bind mounts, and df is reporting the free disk space on the drive where the file is mounted from, that drive being your docker host. You can check with a df on the host (outside of the container) and free up disk space there, or follow whatever procedure is available for your drive and filesystem to expand the available space (e.g. LVM).