Error 0x80070052: the directory or file cannot be created on a share

Fix it now

0x80070052 is Win32 82, “The directory or file cannot be created”. It is a creation failure, not a permission failure: the account has the rights it needs, but something about the name, the path or the destination makes the entry impossible to create. Name, path length and destination limits account for nearly all of it.

1. Create a file called test.txt in the same destination folder. If that succeeds, the problem is the name or the path length, not your permissions.
2. Count the whole path, not just the file name. A path beginning with a server and share name spends a good part of the budget before your own folders start.
3. Check the name for characters the file system will not accept, for a trailing dot or space, and for reserved device names such as CON or LPT1, which stay reserved even with an extension added.
4. Map a drive to a folder further down the tree, so the path the application sees starts there and is much shorter. That is the fastest real fix on a share.
5. Check whether a quota applies to the destination folder or to the user, and how much of it is left. A quota reports free space differently from the volume.
6. If you are writing to the very top level of a share on removable media or an older file system, create a subfolder and write into that instead.

Test as the affected user, not as an administrator. An administrator with a short home path and no quota will succeed at every one of these tests and prove nothing.

If the file saves under its real name to the real destination, you are done. If not, the next section narrows down which of the four limits you have hit.

Why it happens

Creating a file asks the file system to add an entry to a directory, and that can fail for reasons that have nothing to do with who you are. The name may contain something the file system cannot store. The full path may be longer than the interface used to create it can express. The directory itself may be unable to take another entry, which is a real limit on the root of some older file systems and on some appliance file systems. Or a quota may have been reached, in which case the write is refused however generous the permissions read.

Path length is the most common of these on a share, because a network path spends characters before it starts. The same tree that works locally under a short drive letter can exceed the limit through a server and share name, which is why the failure follows the route rather than the data. Windows can permit longer paths, but each application also has to be built to use them, so it is not the quick win it looks like.

The neighbouring codes distinguish the near misses, and it is worth reading which one you actually got. 0x80070050 is Win32 80, “The file exists” – a collision rather than a refusal, and it can be caused by a name differing only in case. 0x800700A1 is Win32 161, “The specified path is invalid.” 0x8007006F is Win32 111, “The file name is too long.” The fourth, 0x80070051, has no published meaning at all: decimal 81 is simply absent from Microsoft’s error list, which runs from 80 straight to 82.

Full reference

The five codes, and the one that is not documented

It is worth being blunt about 0x80070051. Advice that assigns it a meaning is inventing one. If it is what you have, work through the same list of causes as for 0x80070052 – name, path length, destination limits, quota – and do not let anyone tell you the number narrows it down.

Narrowing it down quickly

Reserved names and characters

The rules here are old and are not going to change, so it is worth knowing them once rather than rediscovering them per incident.

• Reserved device names such as CON, PRN, AUX, NUL, COM1 to COM9 and LPT1 to LPT9 cannot be used as file names, with or without an extension.
• A name may not end in a dot or a space. Some interfaces accept the name and strip it silently, others refuse, which is why the same operation succeeds in one application and fails in another.
• The characters reserved by the file system cannot appear in a name, and a name generated from a document title or an email subject is the usual way one sneaks in.
• Case is not significant on a Windows file system, so two names that differ only in case are one name.
• A folder and a file cannot share a name in the same directory.

The path length problem, in practical terms

The well-known limit is 260 characters for a path expressed through the ordinary interface, and the important part is that it counts everything. A share reached as \\fileserver01\departments$\finance has already spent a good share of the budget before the user’s own folder structure begins, which is exactly why the same tree is fine on the server and fails over the network.

1. Map a drive as deep into the tree as the work allows. Every level you skip is characters back.
2. Rename the offending levels rather than the leaves. One long name repeated at four levels costs four times as much as a long file name once.
3. Check what the application does. Some create temporary files alongside the target with longer names, so a path that fits can still fail on the save.
4. Only then consider enabling long paths, and test the applications that matter before relying on it.

Enabling long path support affects every application on the machine, and some older software behaves unpredictably once paths exceed what it expects. Export the branch before changing it, test with the applications that matter, and prefer restructuring the folder tree where you can.

Every code this article covers

Confirm the fix worked

1. Save the file that was failing, under its real name, to the real destination.
2. Create and delete a test file at the deepest point of the tree that is actually used.
3. Confirm quota headroom on the destination if a quota was involved.
4. Repeat the operation as the affected user, not as an administrator.
5. If you shortened a mapping or a folder name, confirm anything that referenced the old path still works.

Questions people ask about this