Fix 0XC019000A: Remote share won't support transacted file ops

Quick answer

Disable transactional NTFS (TxF) on the remote server or bypass transacted operations by using a non-transacted API — reg add HKLM\System\CurrentControlSet\Control\FileSystem /v NtfsDisableTransaction /t REG_DWORD /d 1 /f then reboot.

What's going on here

You're trying to perform a transacted file operation — like copying a file with CopyFileTransacted or using a backup tool that wraps calls in a transaction — against a remote share that doesn't support it. The culprit here is almost always a mismatch: the client expects TxF support, but the remote server (often an older SMB share, a NAS device, or a Linux Samba server) doesn't implement the necessary NTFS transaction semantics. Microsoft deprecated TxF starting with Windows 10, so this error shows up more now. I've seen it most often when people try to use robocopy with the /IPG flag on a network drive, or when a legacy backup agent like Arcserve pushes transacted writes to a Windows share on Server 2012 R2.

Fix steps

Check if the remote server supports TxF. Run fsutil fsinfo ntfsInfo X: on the remote machine (where X: is the drive). Look for Transactions — if it says Not Supported, you're out of luck. Most Samba shares and NAS devices don't support it.
Disable TxF on the remote server (if it's a Windows box). Open PowerShell as admin and run:
```
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\FileSystem' -Name 'NtfsDisableTransaction' -Value 1 -Type DWord
Restart-Computer
```
Reboot required. This kills TxF across the whole server, but honestly, nothing modern uses it anyway.
If you can't touch the server, change the source app. Most backup and file-copy tools let you disable transactions. For example, in robocopy, add /MON:1 /MOT:1? No — instead, remove the /EFSRAW or /B flags that might trigger transacted mode. Try robocopy /E /COPY:DAT /Z /R:3 /W:10 — that avoids the transactional path.
Switch to a local copy. Map the remote share locally, then copy using plain Copy-Item in PowerShell or drag-and-drop. Those don't use transacted APIs.
Update the remote OS. If it's a Windows Server 2008 or 2008 R2, upgrade to at least Server 2016. Old SMB dialects sometimes drop TxF support mid-connection.

Alternative fixes if the main one fails

Disable transactional calls on the client side via a registry key: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System — create EnableTransactionalCalls as DWORD with value 0. This is a sledgehammer approach and can break some Microsoft Office features. Test first.
Use a third-party copy tool that bypasses Windows APIs entirely. FastCopy or TeraCopy don't use TxF. I've used FastCopy for years — it just works.
Set the remote share to a newer SMB protocol version. On Windows Server, open PowerShell: Set-SmbServerConfiguration -EnableSMB2Protocol $true -Force. SMB 3.x handles transactions differently than SMB 1.0.
If it's a Samba share, add nt acl support = yes and kernel oplocks = no to smb.conf, then restart Samba. Not a guarantee, but I've seen it reduce transaction-related errors.

Prevention tip

Don't rely on TxF for anything new. It's deprecated, removed entirely in Windows Server 2022 and Windows 11, and hasn't been needed since Windows 7. If you're building a backup or file-sync solution, use Volume Shadow Copy (VSS) instead — it's supported everywhere and doesn't crap out on remote shares. For existing scripts, run a simple test: Test-Path -Path '\\server\share\test.txt' -IsValid before starting the actual operation, and fall back to non-transacted copy if it fails.