Introduction

This Rails error usually means your application or lockfile still depends on mimemagic version 0.3.5, but that version is no longer available from the source Bundler is using. In Docker, the problem is often amplified by cached layers and persistent bundle volumes, which make it look like code changes did nothing even after you edit the Gemfile or lockfile.

Why mimemagic-0.3.5 Breaks

The root problem is usually not Docker itself. It is dependency resolution around an old or yanked gem version. Historically, mimemagic caused breakage in Rails ecosystems because certain versions disappeared or became unusable for fresh installs.

If your Gemfile.lock still references mimemagic (0.3.5), a clean install can fail even if an older machine used to build successfully.

Confirm the Dependency Path

Start by finding who is pulling the gem in.

bundle why mimemagic
grep -n "mimemagic" Gemfile.lock

In many Rails apps, the dependency chain runs through activestorage and related gems such as marcel.

Knowing the path matters because the correct fix might be:

• updating a direct gem dependency
• updating Rails or Active Storage
• refreshing the lockfile

Fix the Lockfile First

If the project can accept newer dependency versions, update the relevant gems and regenerate the lockfile.

bundle update mimemagic marcel rails

If mimemagic is not direct, update the parent dependency instead:

bundle update marcel activestorage

Commit the new Gemfile.lock so the Docker build uses the corrected dependency graph rather than the stale one.

Rebuild Docker Without Stale Bundle State

Docker often preserves old bundle layers or named volumes. After fixing the lockfile, rebuild cleanly.

docker compose build --no-cache
docker compose down -v
docker compose up --build

The -v flag removes named volumes, which matters if your gems are stored in a persistent bundle volume. Without that step, the container may keep reusing a broken install state.

Example Dockerfile Pattern

A typical Rails Dockerfile installs dependencies during image build.

1FROM ruby:3.2
2
3WORKDIR /app
4
5COPY Gemfile Gemfile.lock ./
6RUN bundle config set without 'development test' \
7 && bundle install
8
9COPY . .
10CMD ["bin/rails", "server", "-b", "0.0.0.0"]

This works well if the lockfile is valid. If the lockfile points to an unavailable gem version, Docker will fail consistently until you update the dependency set.

If the App Is Pinned to Old Rails

Older Rails applications may not be able to take a broad upgrade immediately. In that case:

1. identify the narrowest safe gem update
2. update only the dependency chain causing the missing version
3. run the application test suite
4. rebuild the container from a clean state

If the dependency chain is too old to resolve cleanly, the real fix may be upgrading the Rails version rather than trying to preserve a broken lockfile forever.

Debugging Inside the Container

If the Docker build still seems inconsistent, inspect from inside the container.

docker compose run --rm web bundle env
docker compose run --rm web bundle install
docker compose run --rm web ruby -v

This helps distinguish three different problems:

• dependency resolution failure
• stale bundle cache
• Ruby or Bundler version mismatch

Prevention Practices

The main prevention habit is not to rely on old lockfiles without periodically refreshing them in a clean environment. Build from scratch occasionally in CI or locally so yanked or unavailable gem versions are discovered before a new teammate or deployment pipeline hits them first.

It also helps to keep Docker dependency installation steps isolated and deterministic, with the lockfile copied before the rest of the source tree.

Common Pitfalls

The most common mistake is editing the Gemfile and forgetting that the real broken reference lives in Gemfile.lock. Another is rebuilding Docker without clearing the bundle volume, which preserves the old failure state. Teams also sometimes blame Docker networking when the dependency itself is simply unavailable. Finally, trying to pin more old gems around the problem can make the dependency graph even harder to recover than a focused update would.

Summary

• The error usually comes from a stale dependency on mimemagic-0.3.5, not from Docker alone.
• Use bundle why and inspect Gemfile.lock to find the source of the dependency.
• Update the relevant gems and regenerate the lockfile.
• Rebuild Docker without cache and clear bundle volumes if needed.
• If the app is too old to resolve cleanly, a Rails dependency upgrade may be the real fix.