When FFmpeg reports “Permission denied” while reading playlist videos on Linux, first identify the account running the process and check that account’s access to the playlist, every referenced video and each directory in their paths. The error alone does not tell you which path was denied.
If the log instead says “Unsafe file name” while using the concat demuxer, do not start changing file permissions. That is a separate path-validation check; identify which concatenation method and option are involved before adjusting anything.
Identify the account running FFmpeg
The account at your terminal may not be the account running the command that fails. A command started by a system service, scheduled job, container or media application can run with a different user and group. Permissions that let you read a video interactively therefore do not prove that FFmpeg can read it in its actual execution context.
Start by locating the failing invocation and its launch context. If you started FFmpeg directly in a shell, id shows that shell’s user and group memberships. If a service launches it, inspect the service configuration for the configured user and group, then examine the running process if it is still present. A scheduled task or application may have its own settings. Do not assume that a shell test as your login account represents those contexts.
Run the same diagnostic command as the account that runs FFmpeg, where you can do so safely. The aim is not to change anything yet, but to see whether that identity can traverse the path and read the files. If you cannot run a shell as that identity, use the process or service configuration to establish the identity, then inspect the path permissions against its groups and any applicable ACLs.
This distinction matters on an always-on channel. A playlist may work when you test it after logging in, then fail when a nightly restart or service launch runs under another account. For a headless setup, the advice in running FFmpeg without a desktop environment is useful context, but a headless process still has a specific identity and filesystem access.
Record the account, groups and exact command context before moving on. If FFmpeg runs in a container, also consider that the paths visible inside it may differ from the host paths. An account name that exists on the host is not, by itself, evidence that the process inside a container has the same access.
Check access to the playlist file
The concat demuxer reads a text script containing file entries and other directives, then processes the listed files sequentially. The playlist itself is one of the files FFmpeg must open. Check it separately from the videos, using the account identified above.
Use ls -l /path/to/list.txt to inspect the playlist’s owner, group and mode. Then check the directories leading to it with namei -l /path/to/list.txt. Reading a file generally requires read access to that file and search, or traverse, permission on every directory in the path. A readable playlist can still be unreachable if one parent directory blocks traversal.
If your system uses access control lists, inspect those too, for example with getfacl /path/to/list.txt and the relevant directory paths. A basic owner-and-mode listing does not always show the full access picture. These commands are diagnostics: they do not establish the cause until interpreted against the FFmpeg account and its group memberships.
Check that the path in the command points to the playlist you intend to test. A relative playlist path is resolved from the process’s working directory, which may not be the directory you expect when a service starts. Confirm the service’s working directory or use a known absolute path for the diagnostic test. If FFmpeg cannot open the playlist at all, debugging individual video permissions will not address that first failure.
Do not make the playlist world-readable or change its parent directories recursively just to see whether the error disappears. First determine which specific access check fails and whether a narrower change can give the required account read access while preserving the existing access boundaries.
Check access to every referenced video
A readable playlist does not guarantee that its entries can be opened. Inspect each file entry and check the corresponding video as the FFmpeg account. One inaccessible item can stop processing even if the playlist and the rest of the files are readable.
For each entry, resolve the path as FFmpeg resolves it, then inspect the file and every directory in its path. For example, ls -l /media/channel/clip.mp4 shows file ownership and mode, while namei -l /media/channel/clip.mp4 reveals the permissions of each path component. If the file is owned by a different user, check whether the FFmpeg account has the required access through its group memberships or an ACL.
Pay attention to directory traversal as well as file read access. A file can appear readable in a listing, yet the process may lack permission to search one of the directories above it. Network mounts, removable media and container bind mounts can also impose access conditions that differ from an ordinary local directory; check the relevant mount and runtime configuration rather than assuming the file’s mode is the only factor.
A useful isolation test is to ask FFmpeg to open one listed video on its own, under the same identity and in the same execution context as the failing job. If it fails on that single file, focus on the file and directory access. If it succeeds but the playlist does not, turn to playlist syntax, path resolution, safe-mode validation or a different entry later in the script. Test entries individually if the failure may occur after the first file.
The same checks help when the playlist is part of a longer workflow. If the eventual goal is a continuous channel, keeping a YouTube playlist schedule running on a Raspberry Pi involves more than file access, but the process must still be able to reach every item when the schedule runs unattended.
Verify playlist paths and quoting
Read the playlist as text, not just as a list of filenames you expect to be there. Check every file line for spelling, case, whitespace, relative or absolute paths, and unexpected characters. Resolve each path to the intended file. A path that looks plausible from your shell may refer somewhere else when FFmpeg is launched from a service with a different working directory.
The concat demuxer’s script syntax has its own quoting rules. FFmpeg’s documentation says that special characters and spaces in a path need to be escaped or enclosed in single quotes. A line containing a space in a filename can therefore be parsed differently from what you intended if it is not represented correctly. Do not assume that shell quoting rules and concat-script quoting rules are interchangeable: the shell parses the command line, while the demuxer parses the text file later.
If you use the optional ffconcat version 1.0 signature, FFmpeg documents that it must be exactly on the first line for automatic script recognition. Check for a byte-order mark, leading whitespace or another line ahead of it if recognition behaves unexpectedly. This is a syntax and detection issue, not proof that Linux denied file access.
A small, controlled test playlist can help separate parsing problems from access problems. Put one known video entry in a temporary script using the documented syntax, then run the same FFmpeg command under the same account. Avoid replacing the production playlist until you have established which entry or formatting detail is at issue. Preserve a copy before editing so you can restore the original if the test does not help.
Also confirm that your command actually uses the concat demuxer. The word “concat” can refer to different FFmpeg mechanisms, and advice about the safe option applies to the demuxer rather than to every concatenation method. The FFmpeg FAQ on concatenation methods distinguishes the approaches and explains when their media requirements differ.
Distinguish permission errors from unsafe paths
A genuine “Permission denied” message corresponds to an access-denied condition such as EACCES. FFmpeg’s errno table lists EACCES as “Permission denied,” and the Linux errno reference identifies EACCES as error 13. The code does not identify the exact object that caused the failure. Read the surrounding log lines for the path FFmpeg was trying to open, then check that object and its parent directories.
By contrast, a message such as “Unsafe file name” from the concat demuxer indicates that its path checks rejected a playlist entry. That message does not show that the operating system denied read access. Changing file ownership or adding broad read permissions will not, by itself, make a path pass the demuxer’s validation rules.
The wording around the error is important. Capture the complete command and relevant log lines, including the input option and the filename named in the diagnostic. Do not classify the problem from a shortened message copied without context. The path may be the playlist, a listed video, or a component in either path; the log and access checks narrow it down.
If one file opens directly but the playlist fails with an unsafe-name diagnostic, investigate the concat demuxer’s safe-path behaviour. If the playlist or a video fails with an access-denied message when tested under the FFmpeg account, investigate filesystem access. If the log reports another error, follow that message rather than applying either fix by habit.
Investigate concat demuxer safe rules
The concat demuxer’s safe option controls whether it accepts paths in the script. FFmpeg documents the default as safe=1. Under that setting, it rejects paths that contain a protocol specification, are not relative, include characters outside its documented portable character set, or contain a path component beginning with a period. These are validation criteria applied to the playlist entry, not Linux read-permission checks.
For a trusted playlist whose path entries do not meet those rules, -safe 0 permits filenames that the default validation rejects. Place the option before the relevant concat input in the command, for example ffmpeg -safe 0 -f concat -i /path/to/list.txt .... Confirm this syntax against the installed FFmpeg version and the method actually being used. The online FFmpeg formats documentation describes the concat demuxer and its options; the documentation for an older or distribution-patched build may differ.
There is a trade-off: disabling this check accepts a wider range of paths. Use it only when you control and trust the playlist contents. If entries can be supplied by someone else, retaining path validation or correcting the script to use acceptable relative paths may be the more appropriate choice. Do not set -safe 0 as a generic permission fix, and do not add it to a concat filter or concat protocol command as though they were the demuxer.
The concat demuxer also expects compatible inputs: FFmpeg’s documentation says the files must have the same streams, including codecs and time bases. If the files need re-encoding to join correctly, the concat filter may suit the task better; the concat protocol is for file-level concatenation supported by the formats involved. The FFmpeg concatenation FAQ is not a substitute for the official syntax reference, but can help frame the practical choice between running a command yourself and another streaming workflow.
Fix only the inaccessible path
Once you know the FFmpeg account and the exact inaccessible path, make the smallest change that gives that account the access it needs. Depending on the setup, that could mean granting read access to a specific file, adding the service account to an appropriate group, adjusting a narrow directory’s traverse access, or moving the media to a location the process can already read. Choose a method that fits how the account and media are managed on that system.
Avoid recursive changes across a home directory or media tree, and do not use blanket world-writable permissions as a troubleshooting shortcut. Such changes affect more than the one process and file that need attention. They may also expose or allow modification of material that should remain private or protected. First document the current ownership and permissions so that a change can be reviewed and reversed if needed.
After a targeted change, test the exact file as the FFmpeg account. Then run the playlist under the same service, job or container context that originally failed. If a single file works but the full list does not, check later entries and script syntax rather than widening access further. If all paths pass those checks but the log still names another error, investigate that error on its own terms.
For a 24/7 YouTube channel, repeat the test after the same restart or scheduled launch that would run overnight. A command that works only in an interactive terminal is not a confirmed fix for an unattended process. Keep the playlist and media in a stable location, and make sure any service configuration continues to use the intended account and working directory.
If maintaining a local FFmpeg process and its file access is the specific burden you are trying to remove, StreamNeo lets you upload a video and run it as a 24/7 YouTube live stream without keeping your computer switched on. It is YouTube-only, so this does not resolve a Linux permission problem in an existing FFmpeg setup; it changes the operating arrangement instead.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
What does “Permission denied” mean in FFmpeg?
It indicates that the process was denied access to an object it tried to open, but it does not say which path failed. Check the full log, identify the FFmpeg account, then inspect the playlist, the referenced video and every directory component under that identity.
Why can I read the video but FFmpeg cannot?
Your shell may run as a different user or group from the service, scheduled task, container or application that launches FFmpeg. Test in the actual execution context and inspect the account’s file, directory and ACL access rather than relying on your interactive login.
Does -safe 0 fix Linux permissions?
No. It changes the concat demuxer’s path-validation behaviour and can allow entries rejected by its default safe-path rules. Use it only for a playlist you trust; it does not grant an account permission to read a file or traverse a directory.
Should I change permissions recursively to make the playlist work?
Not before identifying the process identity and exact inaccessible path. Make only the targeted access change needed by that account, then test the individual file and the playlist in the same context that runs the job.