apple / apple/container

[Bug]: `container build` reports "dockerfile not found in context dir" when the context is unreadable

Open
#2,089 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Swift
Stars
49.9k
Forks
1.8k
Avg merge
1d 20h
Merged PRs (30d)
22

Description

### I have done the following

- [x] I have searched the existing issues
- [x] If possible, I've reproduced the issue using the 'main' branch of this project

### Steps to reproduce

```
mkdir ctx
printf 'FROM alpine:3.22\n' > ctx/Dockerfile
chmod 000 ctx
container build ctx
```

Output:

```
Error: dockerfile not found in context dir
```

Naming the file explicitly produces the honest error:

```
container build -f ctx/Dockerfile ctx
Error: ... "You don't have permission to view it." ... NSPOSIXErrorDomain Code=1 "Operation not permitted"
```

### Problem description

`FileManager.fileExists` answers `false` both for a file that is absent and for one the process may not look at, and `BuildCommand.validate()` reports the first for both. The message sends the user to inspect a build context that was never the problem — the `-f` path shows the real error was available and discarded by the earlier check.

Beyond the chmod repro above, this is the ordinary case whenever the CLI runs sandboxed (for example, embedded in an application bundle), where reading the user's project directory is denied by default rather than exceptional.

The fix we run in production distinguishes the two cases by attempting `contentsOfDirectory` on the context when default resolution fails: a denial errors, while a directory that genuinely holds no Dockerfile lists fine. Only the default-resolution path needs it. Happy to open a PR.

### Environment

- OS: macOS 26.6 (25G72)
- Xcode: 26.6 (17F113)
- Container: 1.2.0 (`validate()` unchanged on main at abff418)

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Contributor guide

Open the contributing guide

Research direction

Start at BuildCommand.validate() and reproduce the issue with an unreadable ctx directory using the commands in the report. Inspect the default Dockerfile-resolution path and how contentsOfDirectory distinguishes permission denial from an empty directory. Done means an unreadable context reports the underlying permission error, while a readable context without a Dockerfile keeps the missing-file error.

Written by the indexing model from the issue text.

Assessment

Tech stack
swift
Domain
cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.