What causes "Could not read file: ${file}" in GoogleContainerTools/jib?

Fix read permissions on the classes output directory and files

Could not read file: ${file}

Error message

Could not read file: ${file}

What it means

During main class discovery, Jib logs this warning when a candidate .class file cannot be read from disk (IOException), then skips it. Main class detection continues with the remaining files; only when zero or multiple main classes remain does the build fail separately.

Source

Thrown at jib-core/src/main/java/com/google/cloud/tools/jib/api/MainClassFinder.java:246

        if (mainClassVisitor.visitedMainClass) {
          mainClasses.add(reader.getClassName().replace('/', '.'));
        }

      } catch (IllegalArgumentException ex) {
        throw new UnsupportedOperationException(
            "Check the full stace trace, and if the root cause is from ASM ClassReader about "
                + "unsupported class file version, see "
                + "https://github.com/GoogleContainerTools/jib/blob/master/docs/faq.md"
                + "#i-am-seeing-unsupported-class-file-major-version-when-building",
            ex);

      } catch (ArrayIndexOutOfBoundsException ignored) {
        // Not a valid class file (thrown by ClassReader if it reads an invalid format)
        logger.accept(LogEvent.warn("Invalid class file found: " + file));

      } catch (IOException ignored) {
        // Could not read class file.
        logger.accept(LogEvent.warn("Could not read file: " + file));
      }
    }

    if (mainClasses.size() == 1) {
      // Valid class found.
      return Result.success(mainClasses.get(0));
    }
    if (mainClasses.isEmpty()) {
      // No main class found anywhere.
      return Result.mainClassNotFound();
    }
    // More than one main class found.
    return Result.multipleMainClasses(mainClasses);
  }
}

View on GitHub (pinned to fb949e2676)

Solutions

Fix read permissions on the classes output directory and files
Run a clean rebuild to regenerate a consistent classes directory
Ensure no concurrent process deletes files while the build runs
Specify the main class explicitly so discovery is not needed

Example fix

// before (shell)
chmod 600 target/classes/com/app/Main.class
mvn jib:build
// after
chmod 644 target/classes/com/app/Main.class
# or skip discovery entirely:
mvn jib:build -Djib.mainClass=com.app.Main

Defensive patterns

Strategy: validation

Validate before calling

// Pre-check that all files in the classes dir are readable
try (var s = java.nio.file.Files.walk(classesDir)) {
  s.filter(java.nio.file.Files::isRegularFile)
   .filter(p -> !java.nio.file.Files.isReadable(p))
   .forEach(p -> System.err.println("Unreadable class file: " + p));
}

Prevention

Ensure the classes output directory has uniform read permissions
Avoid concurrent builds writing/deleting the same classes directory
Set the main class explicitly to bypass discovery

When it happens

Trigger: MainClassFinder.find() catches IOException from reading a class file's bytes (permission problems, file deleted mid-scan, I/O errors) and logs "Could not read file: <file>".

Common situations: Files with restrictive permissions in the classes directory; build output being concurrently modified during scanning; unreadable mounted volumes in containerized builds.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors

AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/00c0abc5a1f32874. Report an issue: GitHub.