Question 82785 in Docker Question posted in
The official documentation can be found here.

Running docker containers on a different drive due to host being full

I’ve been using portainer to set up various docker containers and stacks. I recently set up a deluge container, which after being halfway through a large download, threw an error stating that there was no more space left on the machine for saving torrent info.

The stack uses two mounted volumes that point to a mounted CIFS drive of 1TB like so:

version: "3.1"
services:
  deluge:
    image: lscr.io/linuxserver/deluge:latest
    container_name: deluge
    environment:
      - PUID=1001
      - PGID=1001
      - DELUGE_LOGLEVEL=error #optional
    volumes:
      - /mnt/sbox1/docker/deluge/config:/config
      - /mnt/sbox1/docker/deluge/downloads:/downloads
    ports:
      - 8112:8112
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

This seemed strange to me since the error was pointing to a file in a /tmp directory that was not present in the host machine, so I run the ls -lh /tmp command inside the container and found it. From what I understand, since docker is installed inside the host’s /var/lib/docker directory, any containers that I set up, will be using the host for any /tmp data and in cases such as this, that won’t suffice. What are my options here? I tried running docker-compose up on the mounted /mnt/sbox1/docker/deluge dir, but since it uses the host’s docker, it fails with the same issue.

Can I somehow specify to docker (through Portainer preferably) that I want a container to use the storage space on the new mounted drive instead of the space on the host? Would something like adding a mapping to the container’s /tmp path suffice?

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    Thankfully, I managed to fix it, along with @Pierre B.'s help. It seems like the position of the vers=3.0 argument matters (I wasn't aware), and after moving it to the left instead of the end of the fstab entry, it worked and is now mounting as expected during startup. Here's my /etc/fstab entry:

    //[REDACTED].your-storagebox.de/backup /mnt/sbox1 cifs vers=3.0,credentials=/etc/backup-credentials.txt,iocharset=utf8,uid=www-data,forceuid,gid=root,forcegid,file_mode=0777,dir_mode=0777 0 0

    After editing it, performing a reboot or mount -a fixed everything up and now dmesg | grep CIFS doesn't show any errors.


  2. 0

    Indeed you can setup your docker-compose.yml to mount container’s /tmp on your large disk, for example:

    version: "3.1"
services:
  deluge:
    image: lscr.io/linuxserver/deluge:latest
    container_name: deluge
    environment:
      - PUID=1001
      - PGID=1001
      - DELUGE_LOGLEVEL=error #optional
    volumes:
      - /mnt/sbox1/docker/deluge/config:/config
      - /mnt/sbox1/docker/deluge/downloads:/downloads
      # Mount container's /tmp on large disk
      - /mnt/sbox1/docker/deluge/tmp:/tmp
    ports:
      - 8112:8112
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

    through Portainer preferably

    It looks like you’re using a docker-compose.yml file, in that case I would advise against your container directly in Portainer directly (appart for debugging purposes): any change in your docker-compose.yml would re-create container with previous volume definition.

    What are my options here?

    Appart from mounting a volume, you can:

    • You could change your Docker daemon config to use a folder on your large disk rather than /var/lib/docker using --data-root flag, but that seems overly complex for your problem (you would have either to re-install Docker or move all data into new directory)
    • Change Deluge’s behavior to put temporary files under another directory such as /downloads/tmp. But using Docker volume config seems the simpler way in your case, such patterns for mounting /tmp are quite common.

    EDIT: to answer comment

    it seems to me that Deluge IS writing the data on the /mnt/sbox1 mounted CIFS drive but for some reason they take up space on the Host

    Indeed, as you said every Docker container’s data is stored under /var/lib/docker by default. This will include all data written into your container writable layer unless they’re bind-mounted (volumes will also be created under /var/lib/docker/volumes). In other words, everything in your container / will be somewhere in /var/lib/docker/....

    Your container probably writes somewhere – like /tmp and other directories – while downloading, that’s why you see such disk usage. You can try to debug while downloading using du -sh /* or such in your container to identify disk usage.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search