Lesson 3.4: tmpfs Mounts

Welcome to Lesson 3.4! You've learned about volumes for persistent data and bind mounts for host-managed storage. Now we'll explore tmpfs mounts – a special type of mount that stores data only in the container's memory. tmpfs mounts are perfect for temporary, sensitive, or performance-critical data that should never be written to disk. By the end of this lesson, you'll understand when and how to use tmpfs mounts effectively.

---

Learning Objectives

TIP

By the end of this lesson, you will be able to:

• Explain what a tmpfs mount is and how it differs from volumes and bind mounts.
• Mount a tmpfs in a container using the --tmpfs flag or --mount type=tmpfs.
• Understand the use cases for tmpfs (temporary files, secrets, cache).
• Configure tmpfs options like size and permissions.
• Recognize the limitations and security considerations of tmpfs.

---

1. What Are tmpfs Mounts?

A tmpfs (temporary file system) mount is a filesystem that exists in memory (RAM) rather than on disk. When you mount a tmpfs inside a container, any files written to that mount are stored in the container's memory and are lost when the container stops or is removed.

Key characteristics:

• In-memory: Data is stored in RAM, making reads/writes extremely fast.
• Ephemeral: Data does not survive container restarts. Actually, tmpfs is ephemeral: data is lost when the container stops.
• Isolation: Each container gets its own tmpfs instance; data is not shared between containers.
• No persistence: There's no way to recover data after the container is gone.

tmpfs mounts are part of Linux and are supported by Docker on Linux hosts (and on Docker Desktop via the Linux VM).

---

2. Why Use tmpfs?

• Sensitive data: Store secrets, tokens, or credentials that should never be written to disk.
• Temporary files: Application caches, session data, or temporary uploads that don't need to survive a restart.
• Performance: High-frequency writes that would otherwise cause disk I/O bottlenecks.
• Preventing accidental persistence: Ensures data is not inadvertently saved to a volume or bind mount.

tmpfs is not a replacement for volumes; it's a complementary tool for specific scenarios.

---

3. Using tmpfs in Docker

There are two ways to create a tmpfs mount: the --tmpfs flag (simpler) or the --mount flag (more explicit). Both are available in docker run and docker create.

3.1. Using --tmpfs

Syntax:

--tmpfs CONTAINER_PATH[:OPTIONS]

• CONTAINER_PATH is where the tmpfs will be mounted inside the container.
• Options (comma-separated, no spaces):
  • rw (read-write) or ro (read-only) – default is rw.
  • noexec (prevent execution), nosuid, nodev – standard mount options.
  • size=<bytes> (e.g., size=100m or size=1g) – limit the size of the tmpfs.
  • uid=<uid>, gid=<gid> – set owner/group.

Example:

docker run --rm -it --tmpfs /tmp:rw,size=100m,noexec alpine sh

This mounts a tmpfs at /tmp with a 100 MB size limit and disallows execution of binaries.

3.2. Using --mount

The --mount flag provides more clarity and is preferred in automation.

Syntax:

--mount type=tmpfs,destination=CONTAINER_PATH[,tmpfs-size=<bytes>][,tmpfs-mode=<octal>]

• type=tmpfs is required.
• destination is the mount point inside the container.
• tmpfs-size sets the maximum size (in bytes; use 100m or 1g).
• tmpfs-mode sets the directory permissions (octal, e.g., 0700).

Example:

docker run --rm -it \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=100m,tmpfs-mode=0700 \
  alpine sh

3.3. Options Explained

• size: Limits the tmpfs to a maximum size. If the limit is exceeded, the container will get "no space left" errors. Default is half of available RAM on the host.
• mode: Permissions for the root of the tmpfs (e.g., 0700 for owner-only access). Default is 1777 (world-writable with sticky bit) – similar to /tmp on many systems.
• noexec, nosuid, nodev: Standard Linux mount options that restrict execution, setuid binaries, and device files.

---

4. Use Cases in Practice

4.1. Storing Secrets Securely

Instead of writing API keys to a file on disk, you can mount a tmpfs and place secrets there temporarily. Since tmpfs is in memory, the secrets are less likely to be recovered after the container stops.

# Create a container, write a secret to a tmpfs, then use it
docker run --rm -it --tmpfs /secrets alpine sh
# Inside container:
echo "my-secret-token" > /secrets/token
# Use the token...

INFO

For production, use Docker secrets (in Swarm) or Kubernetes secrets for better security.

4.2. Application Caches

Some applications write temporary caches that don't need to persist. By placing them on tmpfs, you improve performance and avoid filling up disk-backed storage.

docker run --rm \
  --mount type=tmpfs,destination=/var/cache/myapp,tmpfs-size=200m \
  myapp

4.3. Testing or Ephemeral Environments

When running tests, you often need a writable temporary directory. A tmpfs ensures that each test run starts with a clean slate and that leftover files don't linger.

docker run --rm -it \
  --mount type=tmpfs,destination=/tmp/build \
  mybuildimage sh -c "cd /tmp/build && make test"

---

5. Limitations and Considerations

• Host-specific: tmpfs relies on the host's memory. On Docker Desktop, it uses the VM's memory, which is limited.
• No sharing: tmpfs mounts are private to the container. They cannot be shared between containers.
• Data loss on restart: If the container restarts (e.g., due to a restart policy), the tmpfs content is lost. For data that must survive restarts, use a volume.
• Memory consumption: Data written to tmpfs consumes host memory. If you write large amounts of data, you risk exhausting memory and triggering OOM (out-of-memory) events.
• Security: While tmpfs does not write to disk, data could still be read from memory if the host is compromised. For highly sensitive data, consider additional encryption.

---

6. tmpfs vs. Volumes vs. Bind Mounts

Feature	tmpfs	Volume	Bind Mount
Location	RAM	Docker-managed disk	Host filesystem
Persistence	Lost on container stop	Persistent	Persistent
Speed	Fastest (RAM)	Disk speed	Disk speed
Use case	Temporary files, secrets	Production data	Dev, config injection
Sharing	Per-container only	Can be shared	Can be shared
Portability	Works on any Linux host	Portable across hosts	Host-specific

---

Hands-On Tasks

Task 1: Basic tmpfs Mount

1. Run an Alpine container with a tmpfs mount at /scratch:

   docker run --rm -it --tmpfs /scratch alpine sh

2. Inside the container, create a file in /scratch and verify it's writable.
3. Exit the container. Since it was run with --rm, it's removed, and the data is gone.

Task 2: Size Limitation

1. Run a container with a tmpfs size limit of 10 MB:

   docker run --rm -it --tmpfs /tmp:size=10m alpine sh

2. Inside, try to create a 15 MB file:

   dd if=/dev/zero of=/tmp/bigfile bs=1M count=15

   It should fail with "No space left on device".
3. Observe the error.

Task 3: Permissions and Mode

1. Mount a tmpfs with restrictive permissions (0700):

   docker run --rm -it --mount type=tmpfs,destination=/secret,tmpfs-mode=0700 alpine sh

2. Inside, as root, check the permissions of /secret with ls -ld /secret.
3. Attempt to write as a non-root user (if you create one). Only root can write because of the 0700 mode.

Task 4: Use tmpfs for a Web Application Cache

1. Create a simple Python script that writes a temporary file (e.g., tempfile.NamedTemporaryFile). Or use a pre-existing image that caches something.
2. Run it with a tmpfs mounted at the cache directory and observe performance or behavior.
3. Compare with a version that uses a regular directory (e.g., a volume) – you can use docker stats to see memory usage.

Task 5: Combine tmpfs with Volumes

1. Run a container that uses both a volume (for persistent data) and a tmpfs (for temporary files). Example: a database container that stores data in a volume but logs to tmpfs.
2. Verify that the tmpfs data disappears on restart while the volume data persists.

Task 6: Inspect tmpfs Mounts

1. Run a container with a tmpfs mount.
2. On the host, use mount | grep tmpfs or df -h to see if the tmpfs is visible. (On Docker Desktop, this may be inside the VM, but you can still run docker exec <container> mount to see the mounts inside the container.)

---

Summary

Key Takeaways

• tmpfs mounts store data in memory, not on disk.
• They are ideal for sensitive, temporary, or high-performance data.
• Use --tmpfs or --mount type=tmpfs to create them.
• You can set size limits and permissions to control usage.
• Data is lost when the container stops; tmpfs is not for persistence.
• Use tmpfs as a complement to volumes and bind mounts, not a replacement.

---

Check Your Understanding

1. What is the main difference between a tmpfs mount and a volume?
2. How would you mount a tmpfs of size 500 MB at /cache with permissions 0700 using --mount?
3. Give two scenarios where using tmpfs is beneficial.
4. What happens to data in a tmpfs when the container is restarted?
5. Can multiple containers share the same tmpfs mount? Why or why not?
6. What potential risk does a large tmpfs pose to the host system?

Click to see answers

1. A tmpfs mount stores data in RAM (memory), which is lost when the container stops. A volume stores data on disk and persists across container restarts and removals.
2. docker run --rm --mount type=tmpfs,destination=/cache,tmpfs-size=500m,tmpfs-mode=0700 alpine
3. Storing sensitive data (secrets, tokens) that shouldn't be written to disk, and high-frequency temporary files or caches where performance matters.
4. The data is lost. Each container restart starts fresh; there is no persistence.
5. No, tmpfs mounts are isolated per container and cannot be shared between containers.
6. It can consume a large portion of the host's RAM, potentially leading to out-of-memory (OOM) events that could affect other running processes.

---

Additional Resources

• Docker tmpfs mounts documentation
• Linux tmpfs man page
• Docker run reference: tmpfs flags

---

Next Up

In the next lesson, we'll cover Backup and Restore of Volumes – a crucial skill for protecting your persistent data. See you there!