Why Batch Files Fail to Write Output on Network Shares (UNC Paths Explained)

The "Permission denied" error usually has nothing to do with the NAS refusing your account — it happens because your batch script is running in the wrong location. When a script (or the program it launches) references a relative path like output.mkv, that file gets created in the current working directory, and with UNC paths, Windows handles that working directory poorly. The fix is to give the script a proper working directory, either temporarily with pushd or permanently with a mapped drive letter.

Why UNC Paths Break Batch Scripts

A network share addressed directly, such as \\192.168.1.10\Media, is called a UNC path. Batch files date back to the DOS era, and the command processor has a long-standing limitation: it cannot set a UNC path as the current working directory. You can verify this yourself:

1. Open a local folder in Explorer, type cmd in the address bar, and press Enter. The command prompt opens in that folder.
2. Repeat the same in a UNC share window. You'll get an error, and the prompt opens somewhere local instead, typically C:\Windows.

The same thing happens when you run a batch file from a UNC share or drop a UNC file onto it. The script starts, but its working directory falls back to a local folder. If your script then writes a relative output file, FFmpeg tries to create output.mkv in that fallback directory — or fails outright, depending on how the path resolves. The misleading "Permission denied" message is often just the symptom of writing to a location you didn't intend.

Fix 1: Use pushd for a Temporary Mapping

The cleanest solution needs no permanent changes to your system. The built-in pushd command, with command extensions enabled, accepts a UNC path: it automatically assigns a temporary drive letter, switches to that directory, and popd removes the mapping afterward.

For a script that receives a file via drag-and-drop, make the input file's folder the working directory and reference the file by name only:

@echo off
setlocal EnableExtensions
if "%~1"=="" exit /b 1
pushd "%~dp1" || exit /b 1

ffmpeg -i "%~nx1" -map 0 -c:s copy -c:a copy -c:v libx264 -crf 24 -pix_fmt yuv420p -force_key_frames chapters -x264opts level=4.1:ref=4:colormatrix=bt709 output.mkv

popd
pause

Two batch parameter modifiers do the heavy lifting here: %~dp1 expands to the drive and path of the first dropped file, and %~nx1 gives just its filename and extension. Quoting handles filenames with spaces. The || exit /b 1 guard stops the script if the directory change fails, so FFmpeg never runs against the wrong folder. With this version, output.mkv lands next to the source file on the NAS, exactly where you'd expect it.

Note that this still assumes ffmpeg.exe is reachable through your PATH. The conversion always runs on your Windows machine — the NAS merely stores the files.

Fix 2: Map a Permanent Drive Letter

If you work with the share regularly, a persistent drive mapping is more convenient:

• In File Explorer, navigate to the share, right-click the folder, and choose Map network drive (on Windows 11 this may be under the "more options" menu). Pick a letter and enable "Reconnect at sign-in".
• Or from any command prompt: net use X: \\192.168.1.10\Media /persistent:yes

Once mapped, drag files from the X: window onto your script. The script now sees X:\file.mkv — a real drive path — and relative paths resolve correctly without any script changes.

The Elevated Prompt Trap

Drive mappings live in your user profile. If a script or program runs elevated (as administrator), it runs in a different logon session and won't see your mappings. If you need elevated tools to access the share, open an elevated command prompt and run net use X: \\192.168.1.10\Media there. The mapping lasts only as long as that window stays open, but every elevated process launched from it will see the share. Keeping scripts non-elevated avoids this entirely.

If You Still Get Permission Denied

A drive mapping changes where paths point, not what you're allowed to do. If writing still fails after fixing the working directory:

• Check the NAS share's write permissions for your Windows account (guest/read-only access is a common culprit).
• Look for an existing output.mkv that is read-only, or currently open in another program.
• Confirm antivirus or ransomware protection isn't blocking writes to network locations.

Frequently Asked Questions

Does the video conversion happen on the NAS or on my PC?

On your PC. Batch files and ffmpeg.exe execute locally; the NAS is just network storage holding the input and output files. For true on-device processing, the NAS would need to run the encoder itself, e.g., via SSH or a built-in app.

Why does "Permission denied" mention the output file and not the input?

Because reading from a UNC path often still works — the failure hits when the script tries to create output.mkv in a working directory it can't write to, or in an unexpected local folder.

Is pushd or a mapped drive better?

pushd is self-contained: the mapping exists only while the script runs, so it's ideal for scripts you share or run rarely. A permanent mapped drive is more convenient for daily drag-and-drop use and requires no script changes, but it depends on the mapping surviving reboots and isn't visible to elevated processes.

What do %~dp1 and %~nx1 mean?

They're batch parameter modifiers. %~dp1 strips the quotes from argument one and expands to its drive and directory; %~nx1 expands to just the filename with extension. Together they let you switch to the file's folder and operate on it by name.

Can I run the batch file directly from the share without dragging files?

You can, but the same UNC limitation applies — the script's working directory won't be the share. Use pushd "\\server\share\folder" at the top of the script, or double-click it from a mapped drive letter instead.