When you run FFmpeg, it can stop with Permission denied (access is denied). This error is not a syntax mistake in your command — it is a problem with access permissions on files or directories. Once you separate whether the input file cannot be read or the output file cannot be written, the cause is quick to pin down. This article organizes the verification steps and solutions by environment: Linux, macOS, Windows, and Docker.
Tested with: FFmpeg 6.1 (verified against real FFmpeg)
Target OS: Linux / macOS / Windows / Docker
What You Will Learn
- How to tell whether
Permission deniedis happening on the input (read) side or the output (write) side - How to check permissions with
ls -l(files) andls -ld(directories) - Solutions on Linux and macOS (granting permissions with
chmod, writing to a writable directory) - How to avoid Docker volume permission problems with
--user - How to fix file locks and security permissions on Windows
- Why forcing execution with
sudois not recommended
What Permission Denied Means (Input or Output)
Permission denied is an OS-level error meaning “the OS refused access.” The FFmpeg command itself is not wrong. What matters is which file the access was refused for. In most cases, you can determine this from the path shown immediately before the error message.
When the input is refused
input.mp4: Permission deniedIf Permission denied appears after the input file name, it means FFmpeg cannot read the input file. A typical case is that the file is owned by another user (such as root) and you do not have read permission.
When the output is refused
./output/result.mp4: Permission denied
Could not open file : ./output/result.mp4If Permission denied appears after the output path, it means FFmpeg cannot write the output file. Possible causes include not having write permission on the output directory, or the directory itself being mounted read-only.
How to think about separating the two
path → Permission denied
↑ if this path is an input file, it "cannot be read"
↑ if this path is an output file, it "cannot be written"First, look at the path right before the error and confirm whether it is the input or the output side. This alone decides what you need to check next (the input file or the output directory).
Checking Permissions (ls -l / ls -ld)
On Linux and macOS, you can check permissions and ownership with the ls command. This is the starting point for a fix.
Check the input file’s permissions
ls -l input.mp4Example output:
-rw-r--r-- 1 root root 10485760 Jun 8 12:00 input.mp4Here is how to read it.
| Part | Meaning |
|---|---|
-rw-r--r-- | Permissions (owner rw-, group r--, others r--) |
root root | Owner user / owner group |
In this example the file is owned by root. If you are working as a regular user, the “others” permission r-- applies, so you can read it. However, if the owner is root and the permissions are -rw------- (no permission for others), a regular user cannot read it and gets Permission denied.
Check the output directory’s permissions
When you want to look at a directory’s permissions rather than a file’s, add -d.
ls -ld ./outputExample output:
drwxr-xr-x 2 root root 4096 Jun 8 12:00 ./outputThe leading d indicates a directory. Here too, if the owner is root and a regular user has no write permission (w), you cannot write output to that directory. Always check whether the output directory has w (write) permission.
Solutions on Linux and macOS
Once you have separated and verified the issue, try the following depending on the situation.
1. Grant read/write permission on the file
If it is a file you own but the permissions are insufficient, add permissions with chmod.
chmod u+rw input.mp4u+rw— add read (r) and write (w) for the owner (user)- If you only want to read the input file,
chmod u+r input.mp4is fine too
chmod can only be run on files you own. If the owner is another user, it is safer to either have the owner side handle it (as described later) or copy the file into your own directory before working with it.
2. Write to a writable directory
When the output is refused, the simplest and most reliable solution is to write to a directory you can write to. You usually have write permission under your home directory.
ffmpeg -i input.mp4 ~/Videos/output.mp4If you write to a directory you own, such as ~/Videos/ (under your home), output permission problems almost never occur. Cases where you are refused while trying to write directly to a system directory (like /usr/... or directly under /) are solved simply by changing the output destination.
3. Working with files owned by another user
Files created earlier with sudo, or files copied by another user, are owned by root or similar. Check the owner with ls -l, and if necessary, either transfer ownership on the owner side (sudo chown your-username file) or copy the file to a writable location before working with it.
Solutions for Docker
When you run ffmpeg in Docker, a file you write to a volume mount can end up owned by root inside the container, leaving you in a state on the host where you “can’t read or delete your own file.” Also, the container’s user may be unable to write to the mounted directory, resulting in Permission denied.
Run with your current user’s permissions
The basic way to prevent this is to run with --user, specifying your own user ID and group ID from the host side.
docker run --rm -v "$(pwd)":/work -w /work --user $(id -u):$(id -g) jrottenberg/ffmpeg -i input.mp4 output.mp4-v "$(pwd)":/work— mount the current directory to/workin the container-w /work— set the working directory to/work--user $(id -u):$(id -g)— run the container with your own host UID:GID. This makes generated files owned by you and prevents them from becoming root-owned--rm— automatically remove the container after it runs
$(id -u) expands to your user ID and $(id -g) to your group ID. With this, the output files become files you own on the host side, so you can read, write, and delete them normally afterward.
When it still cannot write
- Check with
ls -ldwhether the mounted host-side directory has write permission for the specified UID/GID - In environments where SELinux is enabled (RHEL-based, etc.), adding
:z/:Zto the volume (e.g.,-v "$(pwd)":/work:z) applies labeling and may allow access
Solutions on Windows (Locks and Permissions)
On Windows, the causes of Permission denied (access is denied) tend to differ a bit from Linux/macOS. The most common case is that the file is locked by another app.
1. Release the file lock
On Windows, while one app has a file open, another process may be unable to overwrite or write to that file. Check the following.
- Close any input/output file that is playing in a video player
- The Explorer Preview pane / Details pane can be holding onto the target file, so disable the preview or open a different folder
- Check whether a file with the same name as the output file is open in another app
If it is locked because it is “in use,” simply closing the relevant app (the player, or Explorer’s preview) makes it writable again.
2. Check the folder’s write permission
If you try to write to a location that requires administrator privileges, such as directly under C:\Program Files\ or the root of a drive, you will be refused. The easiest approach is to change the output destination to your own user folder (such as C:\Users\username\Videos\).
If you want to check or change the permissions themselves, right-click the target file or folder → Properties → Security tab, and confirm that your user account has “Write” and “Modify” permissions.
3. Remove the read-only attribute
If “Read-only” is checked in the file’s properties, it cannot be overwritten. Uncheck it in the properties dialog.
Why You Should Not Casually Use sudo
When you get Permission denied on Linux/macOS, forcing execution with sudo ffmpeg ... may seem to work at first glance. However, this causes problems later, so it should not be used casually.
Output created with sudo becomes root-owned
If you run something like sudo ffmpeg -i input.mp4 output.mp4, the generated output.mp4 becomes owned by root. This leads to situations like the following.
-rw-r--r-- 1 root root 20971520 Jun 8 12:30 output.mp4- As a regular user, trying to edit or overwrite it gives Permission denied again
- Subsequent scripts or apps (those running with your own permissions) cannot read or delete that output
- As a result, “files you can’t touch without sudo” pile up, and the permission state grows more and more complicated
The basic principle: “write to your own writable directory”
The correct way to resolve a permission error is not to override permissions with sudo, but to work in a place where you can read and write.
ffmpeg -i input.mp4 ~/Videos/output.mp4Even when the input file is root-owned and cannot be read, the proper approach is to first check ownership and permissions with ls -l, and if necessary perform chown / chmod on the owner side. Limit sudo to “when you genuinely need to touch a system area,” and avoid using it in ordinary encoding work.
FAQ
Two paths appear right before the error and I can’t tell whether it’s the input or output
Trace back through the whole log and identify the path shown immediately before Permission denied. If it is an input file name, it is a read problem; if it is an output file name, it is a write problem. When you can’t tell, just check both ls -l input-file and ls -ld output-directory, and you will immediately see which side is missing permissions.
chmod gives “Operation not permitted” when I try to add permissions
It is very likely that you are not the owner of that file. Check the owner with ls -l. chmod can only be run by the owner (or root). If the owner is root or similar, either handle it on the owner side, or copy the file to a directory you can write to before working with it. Casually applying sudo chmod 777 is not recommended from a permission-management standpoint.
On macOS I get “Operation not permitted” (not Permission denied)
On macOS, TCC (privacy protection) can block the terminal from accessing certain folders such as Desktop, Documents, and Downloads. In this case, you cannot access them even if the permission bits (ls -l) are correct. Granting access to the terminal app you use under System Settings → Privacy & Security → Full Disk Access may resolve it.
A file I output with Docker is root-owned and I can’t delete it
Running docker run with --user $(id -u):$(id -g) makes generated files owned by you on the host side, preventing this problem. For files that have already been created root-owned, transfer ownership to yourself with sudo chown your-username file before working with them.
Related Articles
- FFmpeg Common Errors and Fixes
- Fixing the No such file or directory Error
- FFmpeg Beginner’s Guide
- FFmpeg Command Basic Syntax
Tested with: ffmpeg 6.1
Primary sources: ffmpeg.org/ffmpeg.html / ffmpeg.org/faq.html / trac.ffmpeg.org/wiki/CompilationGuide