MSI 1310 and 1303: The Installer Cannot Write to the Path It Was Given

Fix it now

The installer tried to create a file and the file system refused. The path in the message is the diagnosis, and the system error code printed beside it says what went wrong: denied, in use, or not found. Nothing here indicates a bad package.

msiexec /i "C:\path\to\package.msi" /l*v %USERPROFILE%\Desktop\msi.log
icacls "C:\Program Files\Vendor"
icacls "C:\Program Files\Vendor" /inheritance:e
icacls "C:\Program Files\Vendor" /grant "SYSTEM:(OI)(CI)F" "Administrators:(OI)(CI)F" /T

1. Read the full path from the message, or from the log if the dialog truncated it, and note the system error code beside it.
2. If the file already exists, find what is holding it open: run resmon, go to the CPU tab, and type the file name into the Associated Handles box.
3. Clear read-only and system attributes if something set them: attrib -r -s "C:\Program Files\Vendor\*" /s /d.
4. Run the installer again from the elevated prompt.

Apply the permission commands to the specific product folder in your message, not to the whole of Program Files. A recursive change across the entire tree is slow and flattens permissions other products rely on.

If setup completes without offering to retry or ignore a file, you are done. If not, the next section works through who is doing the writing and why it is being refused.

Why it happens

In a per-machine installation the file copy is performed by the Windows Installer service running as SYSTEM, not by your logged-on account. That single fact explains most of the confusing cases. SYSTEM has broad rights on the local machine, but on the network it presents as the computer account, so a write that leaves the machine needs the computer account to have access, not you.

That is why folder redirection is such a reliable trigger. If Documents, AppData or the Desktop have been redirected to a file server and a package writes into one of those locations during a per-machine install, the write arrives at the share as the computer account. Unless the share grants that account rights, the write fails and the message names a UNC path or a redirected local path.

The numbers in this family are more precise than they look, and it is worth matching yours to the published wording rather than to the phrasing on your screen. 1310 is published as an error attempting to create the destination file, with a system error code attached. 1304 is published as an error writing to a file. 1303 and 1321 are the two privilege cases – insufficient privileges to access a directory, and insufficient privileges to modify an existing file. 1317 is a directory that could not be created, and 1320 is a path that is simply too long.

Many packages display their own wording for these numbers, because the strings the installer shows come from a table inside the package rather than from Windows. The number and the path are the parts that stay reliable, and the system error code inside a 1310 message is the single most useful value on the screen: 5 is access denied, 32 is a sharing violation, 3 is a missing path.

Full reference

The published message for each number

If the dialog on your screen says something different next to the same number – the familiar “Error writing to file … Verify that you have access to that directory” is the common one – that wording came out of the package, not out of Windows. Microsoft publishes the strings above. Diagnose from the number, the path and the system error code, all three of which are stable.

Reading the system error code

Command reference

Cases that look like permissions and are not

• Only .exe or .dll files fail. Real-time scanning is holding files as they are written; exclude the staging folder rather than turning protection off.
• The path is under Program Files but the volume is nearly full. Windows Installer stages before it commits, so it needs room for both copies.
• Every path fails on one machine and none on an identical build. Look at a hardening baseline or a security template before touching individual folders.
• The file exists with a zero byte size. A previous failed install left a stub; delete it and run setup again.
• The target is on removable or encrypted storage that is not unlocked at the point setup runs.

What clicking Ignore actually does

The retry dialog offers Ignore, and it does what it says: the transaction continues and the file that failed is simply absent. Setup then reports success. The application will fail later, at a point that has nothing obvious to do with an installation you performed weeks earlier, and the log that would have explained it is long gone. Fix the path and install properly, or cancel and come back to it.

Every code this article covers

Confirm the fix worked

1. Rerun the installer and confirm it completes without prompting to retry or ignore any file.
2. Open the install folder and confirm the file from the original message is present, with a sensible size and date.
3. Run icacls on the install folder and confirm SYSTEM and Administrators hold full control through inherited entries.
4. Start the application and use the feature that depends on the file that previously failed to copy.
5. If the path was redirected, sign in as a second affected user and confirm the install works there too.

Questions people ask about this