Fix java.io.FileNotFoundException: No such file or directory in Java

The Error

java.io.FileNotFoundException: /path/to/your/file.txt (No such file or directory)
	 at java.base/java.io.FileInputStream.open0(Native Method)
	 at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
	 at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157)
	 at java.base/java.io.FileReader.<init>(FileReader.java:75)
	 at com.example.MyApp.readFile(MyApp.java:12)

Java throws this when it can't open a file — either because the path doesn't point to anything real, or because the process lacks read permission. The stack trace tells you exactly which line triggered it, so start there.

Root Causes

• The file path is wrong — typo, wrong separator, or a hardcoded absolute path that only works on your machine.
• The path is relative, but the JVM's working directory isn't where you think it is.
• The file is inside src/main/resources and you're reading it like a regular filesystem file instead of a classpath resource.
• The file exists but the process doesn't have read permission.
• On Windows, mixing forward slashes and backslashes in a hardcoded path.

Step-by-Step Fix

Step 1 — Print the actual resolved path

Start here. Print the absolute path Java is actually trying to open. This single line solves roughly 80% of cases:

File file = new File("config/settings.txt");
System.out.println("Absolute path: " + file.getAbsolutePath());
System.out.println("Exists: " + file.exists());

Look at what prints. Nine times out of ten, the resolved path is nothing like what you expected — and once you see it, the fix is obvious.

Step 2 — Check the working directory

Relative paths resolve from the JVM's working directory. That's set when the process starts — not where the source file lives.

System.out.println("Working dir: " + System.getProperty("user.dir"));

For Maven/Gradle projects opened in IntelliJ or Eclipse, this is usually the project root. For a packaged JAR, it's whatever directory you were in when you typed java -jar app.jar. Those two environments often resolve to completely different places.

Step 3 — Use the correct path

When the file lives on disk (not bundled in a JAR), pick one of these three approaches:

// Option A: absolute path — no ambiguity
File file = new File("/home/ubuntu/app/config/settings.txt");

// Option B: relative to working directory (verify with Step 2 first)
File file = new File("config/settings.txt");

// Option C: build the path from an environment variable
String basePath = System.getenv("APP_HOME");
File file = new File(basePath + "/config/settings.txt");

For cross-platform code, use NIO's Paths.get() with multiple args instead of string concatenation — it handles OS-specific separators automatically:

Path path = Paths.get("config", "settings.txt");
System.out.println(path.toAbsolutePath());

Step 4 — Reading a classpath resource (resources folder)

Files inside src/main/resources get bundled into the JAR. Once packaged, new File() can't reach them. Switch to getResourceAsStream():

// WRONG — breaks when running from JAR
File file = new File("src/main/resources/config.properties");

// CORRECT — works in both IDE and packaged JAR
try (InputStream is = MyApp.class.getResourceAsStream("/config.properties")) {
    if (is == null) {
        throw new RuntimeException("Resource not found: /config.properties");
    }
    Properties props = new Properties();
    props.load(is);
}

The leading / matters. It makes the path absolute from the classpath root. Drop it, and Java looks relative to the class's package — which is probably not what you want.

Step 5 — Check file permissions

Sometimes the file exists and the path is right, but the JVM still can't open it. That usually means the process is running as the wrong user, or the permissions are too restrictive:

# Linux / macOS
ls -la /path/to/your/file.txt
chmod 644 /path/to/your/file.txt

# Check which user runs the JVM
ps aux | grep java

On Linux, the file needs to be readable by whatever user owns the Java process — not just root. On Windows, check that the file isn't locked by another application like Excel or a text editor left open.

Step 6 — Create the file or directory if it should exist

Writing to a new file? Make sure the parent directories exist first. FileWriter won't create them for you:

File file = new File("/var/app/output/report.txt");

// Create parent directories if missing
file.getParentFile().mkdirs();

// Now safe to create/write
try (FileWriter writer = new FileWriter(file)) {
    writer.write("hello");
}

Verify the Fix

Before running the full app, drop this sanity check into your code:

File file = new File("your/path/here");
if (!file.exists()) {
    System.err.println("File not found: " + file.getAbsolutePath());
} else if (!file.canRead()) {
    System.err.println("No read permission: " + file.getAbsolutePath());
} else {
    System.out.println("OK: " + file.getAbsolutePath());
}

If anything other than OK: prints, the fix isn't complete. Don't skip this step when the error is intermittent — file presence can vary between environments.

Quick Reference

• File on disk, wrong path → print getAbsolutePath(), fix the path string.
• File in resources folder → use getResourceAsStream(), not new File().
• Relative path resolves wrong → print user.dir, adjust the relative path or switch to absolute.
• Permission denied variant → chmod 644 on Linux, or check file locks on Windows.
• Parent directory missing → call file.getParentFile().mkdirs() before writing.