Scan to folder fails with 0xC00000CC: the copier cannot reach your share

Fix it now

0xC00000CC is STATUS_BAD_NETWORK_NAME, which the SMB protocol documentation maps to an invalid name in the tree connect. The device authenticated and then asked for something the server does not publish. That is a naming problem, not a permissions problem, and the usual cause is a path in a field that only takes a share name.

Get-SmbShare | Select-Object Name,Path
Get-SmbSession | Select-Object ClientComputerName,ClientUserName,Dialect
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol

1. Compare the share name the first command returns with the one configured on the device. Put only the top-level share name in the device’s share field, and any subfolder in its separate path or directory field.
2. Create a dedicated local account for the device in Computer Management, Local Users and Groups. Set the password not to expire and clear the requirement to change it at next logon.
3. Grant that account Change on the share and Modify on the folder, and nothing else.
4. In the device’s address book entry, use the machine’s IP address as the host and the account in the form the device expects, normally MACHINENAME backslash user for a local account.
5. Send a one-page test scan from the device’s own send button, then run the second command while it is in flight to see the dialect it negotiated.

Do not fix this by re-enabling SMB1. A copier is one of the least monitored devices on your network, and firmware, a newer device or scan-to-email are all better answers.

If a file lands in the folder you are done. If not, the next section covers what the device is actually asking for and where the request is failing.

Why it happens

Scan to folder is an SMB write. The device resolves your host, opens a session, authenticates, connects to a share by name, then creates a file inside it. The status you are looking at is returned at the share connect step, which is what makes it useful: authentication has already succeeded, so credentials are not the problem. Microsoft’s SMB documentation maps STATUS_BAD_NETWORK_NAME to an invalid name in the tree connect, so what the device asked for does not exist on that server under that name.

The most common reason is that the device sent a whole path where a share name belongs. If your share is called scans and the folder beneath it is reception, the share is scans and reception belongs in the device’s path or subdirectory field. Devices differ in how they split those fields and some prepend or append backslashes on their own, so a configuration that looks right on the panel can produce a tree connect for a share that was never published.

The other structural reason is dialect. SMB1 is not installed by default on current Windows, and a device whose firmware only speaks it fails at or just after session setup rather than at the share. Get-SmbSession tells you what it negotiated while it is connected, which beats reasoning about firmware versions.

Of the companions, one is documented and two are not. 0xC000006E is STATUS_ACCOUNT_RESTRICTION: the user name and authentication information are valid, and an account restriction prevented authentication. 0xC00000BE and 0xC0000388 appear in the same traces with no published meaning, so treat them as prompts to test the host and the dialect.

Full reference

The four statuses and what is actually published

The two blanks are not a failure of diagnosis. Where a status has no published meaning you diagnose by position in the exchange: 0xC00000CC arrives at the share connect, so authentication is already done; anything that fails before that is a session setup problem, which is where dialect and credentials live. That ordering is more reliable than a definition anyway.

Building a scan target that keeps working

1. Create a folder on a machine that stays on, and share it with a short, lower-case, single-word share name.
2. Create a dedicated local account for the device. Password never expires, no change at next logon, no interactive rights.
3. Grant that account Change on the share and Modify on the folder. Nothing else needs access.
4. Give the host a reserved or static address and put that address in the device rather than a name.
5. Send a test scan, then check the file opens and is not zero length, which catches a write that started and stopped.

What the dialect check tells you

Why Explorer works and the copier does not

Explorer negotiates a modern dialect, resolves names through several fallbacks, forgives formatting in the path and retries in ways you never see. The device does none of that. It sends one string, in one form, and accepts one answer. That is why a share path you can open by hand proves almost nothing about what the device will do with it, and why the test that matters is a scan from the device’s own send button rather than a simulation from its web interface.

Re-enabling SMB1 to make a copier work removes a protection from the whole machine, not just from that one connection. If the device is genuinely limited to it, the honest options are firmware, a different scan target, scan-to-email, or replacing the device.

When the share, the account and the dialect all check out

• Check the folder’s own permissions as well as the share’s. Change on the share and no Modify on the folder produces a failure at the write rather than at the connect.
• Check for a file naming collision. Some devices overwrite and some fail, and a device that fails looks like a permissions problem.
• Check free space on the target. A device with no useful error surface reports a full disk as a generic failure.
• Check whether an endpoint security product is scanning the folder and locking files as they arrive.
• Check the device’s own log. Business copiers keep one, and it usually names the step that failed more precisely than the panel does.

Every code this article covers

Confirm the fix worked

1. Send a test scan from the device and confirm a file appears in the folder with a current timestamp.
2. Run Get-SmbSession on the host while the scan is in flight and confirm the device appears with a modern dialect.
3. Open the file and confirm it is complete and readable, not a zero-length placeholder.
4. Confirm the scan account’s password is set not to expire, so the target does not break in ninety days.
5. Reboot the host and send a second scan, to confirm the share and the account survive a restart.

Questions people ask about this