FFmpeg can stop with Permission denied (access is denied). First work out whether FFmpeg could not read the input or could not write the output. Once you know that, the cause is quick to find.

Target OS: Linux / macOS / Windows / Docker

What Permission Denied Means (Input or Output)

Permission denied comes from the operating system: it refused FFmpeg access to a file or directory. The options in your command are usually fine. On Windows, though, a path that points to a folder instead of a file gives the same error, so check the path too. What matters is which file was refused, and the error line tells you: Error opening input for the input, Error opening output for the output.

When the input is refused

[in#0 @ 00000275351b8400] Error opening input: Permission denied
Error opening input file input.mp4.
Error opening input files: Permission denied

Error opening input: Permission denied means FFmpeg cannot read the input file. The next line, Error opening input file, names the file. Typically the file belongs to another user (such as root) and you have no read permission.

When the output is refused

[out#0/mp4 @ 0000024fa9834c80] Error opening output ./output/result.mp4: Permission denied
Error opening output file ./output/result.mp4.
Error opening output files: Permission denied

Error opening output, followed by the output path and Permission denied, means FFmpeg cannot write the output file. Possible causes: you have no write permission on the output directory, or the directory is mounted read-only. When you write an image sequence (such as frame_%03d.png), the message is [image2 @ …] Could not open file : path instead.

How to think about separating the two

[in#0 …]  Error opening input: Permission denied   → the input "cannot be read"
[out#0 …] Error opening output …: Permission denied → the output "cannot be written"

in#0 (Error opening input) or out#0 (Error opening output) at the start of the line tells you which side failed. That decides what to check next: the input file or the output directory.

Checking Permissions (ls -l / ls -ld)

On Linux and macOS, ls shows the permissions and the owner of a file.

Check the input file’s permissions

ls -l input.mp4

Example output:

-rw-r--r-- 1 root root 10485760 Jun  8 12:00 input.mp4

How to read it:

Part Meaning
-rw-r--r-- Permissions (owner rw-, group r--, others r--)
root root Owner user / owner group

Here the owner is root. A regular user falls under “others”, whose permission is r--, so you can read the file. If the owner is root and the permissions are -rw------- (nothing for others), a regular user can’t read it and gets Permission denied.

Check the output directory’s permissions

To see a directory’s own permissions rather than a list of its files, add -d.

ls -ld ./output

Example output:

drwxr-xr-x 2 root root 4096 Jun  8 12:00 ./output

The leading d marks a directory. Here too the owner is root and others have no write permission (w), so a regular user can’t save output in that directory. Check that you have w (write) permission on the output directory.

Solutions on Linux and macOS

1. Grant read/write permission on the file

If you own the file but lack permission, add it with chmod.

chmod u+rw input.mp4
  • u+rw — add read (r) and write (w) for the owner (user)
  • If you only need to read the input, chmod u+r input.mp4 is enough

You can only chmod files you own. If someone else owns the file, have the owner change it, or, if you can still read it, copy it into your own directory and work on the copy (copying needs read permission too).

2. Write to a writable directory

If the output is refused, save it in a directory you can write to. You can usually write anywhere under your home directory.

ffmpeg -i input.mp4 ~/output.mp4

In a directory you own, such as your home directory (~/), output permission problems almost never happen. If you were writing straight into a system directory (like /usr/... or / itself), changing the output location solves it.

3. Working with files owned by another user

Files you created earlier with sudo, or files copied by another user, belong to root or that user. Check the owner with ls -l. If needed, move ownership to yourself (sudo chown your-username file), or, if you can still read the file, copy it somewhere writable and work on the copy.

Solutions for Docker

When you run ffmpeg in Docker, a file written to a mounted host directory (a volume mount) can end up owned by root, because root created it inside the container. On the host you then can’t overwrite or edit your own output. The container’s user may also be unable to write to the mounted directory, which gives Permission denied.

Run with your current user’s permissions

To prevent this, run the container with --user and your own host user ID and group ID:

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 /work in the container
  • -w /work — set the working directory to /work
  • --user $(id -u):$(id -g) — run the container as your host user (UID:GID), so the files it creates belong to you, not root
  • --rm — remove the container when it finishes

$(id -u) expands to your user ID and $(id -g) to your group ID. The output files are then yours on the host, and you can read, change and delete them as usual.

When it still cannot write

  • Run ls -ld on the mounted host directory and check that the UID/GID you passed can write to it
  • Where SELinux is enabled (RHEL-based systems and similar), add :z or :Z to the volume, for example -v "$(pwd)":/work:z. Docker then relabels the directory, which may let the container access it. Never do this with a system directory such as /home or /usr: Docker’s documentation warns that mounting one with :Z makes the host machine inoperable

Solutions on Windows (Locks and Permissions)

On Windows, Permission denied (access is denied) usually has a different cause from Linux and macOS: another app has the file open and locked.

1. Release the file lock

While one app has a file open, other programs may not be able to write to it. Check the following:

  • Close the input or output file if it is playing in a video player
  • File Explorer’s Preview pane or Details pane can keep the file open. Turn off the preview, or open a different folder
  • Make sure no other app has a file open under the output file’s name

Once you close the app that holds the file (the player, or Explorer’s preview), FFmpeg can write to it again.

2. Check the folder’s write permission

Places that need administrator rights, such as C:\Program Files\ or the root of a drive, refuse the write. The easiest fix is to save the output in your own user folder (such as C:\Users\username\Videos\).

To check or change the permissions, right-click the file or folder, open Properties → Security, and check that your user account has “Write” and “Modify”.

3. Remove the read-only attribute

If “Read-only” is checked in the file’s Properties, the file can’t be overwritten. Uncheck it.

Why You Should Not Casually Use sudo

On Linux and macOS, running sudo ffmpeg ... may seem to get past Permission denied. It causes problems later, though.

Output created with sudo becomes root-owned

After sudo ffmpeg -i input.mp4 output.mp4, the new output.mp4 belongs to root:

-rw-r--r-- 1 root root 20971520 Jun  8 12:30 output.mp4
  • Editing or overwriting it as a regular user gives Permission denied again
  • Scripts and apps that run with your own permissions can’t overwrite or change it either
  • Files you can only touch with sudo pile up, and the permissions get harder and harder to sort out

Work in a directory you can write to

Instead of overriding permissions with sudo, work in a place where you can read and write:

ffmpeg -i input.mp4 ~/output.mp4

If the input is owned by root and you can’t read it, check the owner and permissions with ls -l first. Then have the owner run chmod, or have root run chown (only root can change a file’s owner). Keep sudo for work on system areas, not for everyday encoding.

FAQ

I can’t tell from the log whether it’s the input or output

Look at the line that contains Permission denied. [in#0 …] Error opening input means FFmpeg couldn’t read; [out#0 …] Error opening output means it couldn’t write. If you still can’t tell, run both ls -l input-file and ls -ld output-directory and see which side lacks permission.

chmod gives “Operation not permitted” when I try to add permissions

You are most likely not the file’s owner. Check the owner with ls -l. Only the owner (or root) can chmod a file. If root or another user owns it, have the owner change it, or, if you can still read the file, copy it to a directory you can write to and work on the copy. Avoid sudo chmod 777: it gives every user full access to the file.

On macOS I get “Operation not permitted” (not Permission denied)

macOS privacy protection (TCC) can block the terminal from folders such as Desktop, Documents and Downloads, even when the permissions shown by ls -l are correct. Give your terminal app access under System Settings → Privacy & Security → Full Disk Access.

A file I output with Docker is root-owned and I can’t delete it

Run docker run with --user $(id -u):$(id -g) so that new files belong to you on the host. For files that are already root-owned, take ownership first with sudo chown your-username file. Whether you can delete a file depends on write permission on the directory that holds it, not on who owns the file. You can delete a root-owned file in your own directory. To delete files inside a root-owned directory, take ownership of that directory too.