Fix ERROR_TRANSACTIONS_UNSUPPORTED_REMOTE 0X00001A95

Quick answer: ERROR_TRANSACTIONS_UNSUPPORTED_REMOTE (0X00001A95) means an app tried a transacted file operation on a remote SMB share that doesn't support the Transactional NTFS (TxF) API — the fix is to move the data to a local NTFS volume or update the app to use a standard NTFS transaction, not SMB.

Here's what's going on. TxF is the Windows API that lets a program batch a bunch of file operations into one atomic unit — all or nothing. Databases, installers, and a few backup tools lean on it because a half-written file is worse than no file. Problem: TxF only works on local NTFS volumes. Microsoft never shipped a working SMB2 transaction layer for it, and SMB3 doesn't add one either. So the moment your app points at \\server\share\ instead of C:\, the file handle opens fine but the first CreateFileTransacted call returns 0x1A95 and the whole operation aborts.

I hit this last month with a client running a legacy inventory tool. Their IT guy had “optimized” storage by moving the data directory to a mapped network drive. Every nightly reconcile died with 0x1A95. Took me ten minutes to diagnose because the event log pointed straight at it.

How to fix it

Confirm it's the share, not the app. Open Event Viewer and look at Windows Logs > Application and System around the failure time. You'll see the source process, the file path, and the HRESULT 0x1A95. If the path starts with \\ or a drive letter mapped to a UNC path, you've found it.
Check what filesystem is actually hosting the file. From the server, run:
```
fsutil fsinfo volumeinfo C:
```
You're looking for NTFS. FAT32, exFAT, ReFS, and SMB shares mounted from a NAS all lack TxF. ReFS is the sneaky one — people assume it's a drop-in NTFS replacement and it is not, at least not for TxF.
Move the working directory to a local NTFS volume. This is the real fix in 90% of cases. Copy the app's data folder to a local drive on the same machine where the app runs, then repoint the app's config. Don't just symlink it back to the share — the symlink target still gets hit with TxF and you'll be back here tomorrow.
Reconfigure the app to disable transactions. A lot of database engines expose a switch. Microsoft Access, for example, has Use Transaction in the Options > Advanced page for linked-table updates. SQLite has PRAGMA journal_mode. Firebird has --no-transaction style flags depending on the tool. Turn it off, restart, retry. This is a compromise — you lose atomicity — so only do it if the data tolerates partial writes.
Update the app. If it's still shipped by a vendor, check for a release from 2019 or later. Post-Windows 8, most vendors ripped out TxF because Microsoft started deprecating it. A newer build probably uses ReplaceFile or a write-temp-then-rename pattern that works over SMB.

Alternative fixes if that doesn't work

Sometimes you can't move the data — the share is the whole point, maybe because multiple machines need it. In that case:

Try a different SMB dialect. From an elevated prompt on the client, run Set-SmbClientConfiguration -RequireSecuritySignature $false and force dialect 2.1 with Set-SmbClientConfiguration -Smb2DialectMinimum 2.1 -Smb2DialectMaximum 2.1. I've seen this change the failure to a different code (usually access denied or sharing violation) which at least tells you the app is now falling back to non-transacted calls. Rarely a permanent fix, occasionally a useful diagnostic.
Check antivirus. Some AV minifilters intercept file operations and return 0x1A95 as a side effect when their own driver hits a share it can't transact against. Bitdefender and older Kaspersky builds did this. Temporarily disable AV, retry, and if it works, add the data folder to the exclusion list — not the whole drive.
Move to a different protocol. If the app supports a database connection over TCP (SQL Server, PostgreSQL, MySQL) instead of file-share access, use it. Native TCP doesn't use TxF at all. This is the cleanest long-term answer for multi-user setups.

Prevention

Before you point any database or transactional app at a network share, check three things: the server's filesystem is NTFS, the share is on a Windows host (not a Linux Samba box, not a NAS running Btrfs or ZFS), and the app's docs mention Windows 8+ support. If any of those fail, plan on keeping the data local and using replication or a proper client-server protocol for multi-machine access. Treat any 0x1A95 that shows up in your logs as a red flag that someone moved a working directory onto a share they shouldn't have.

One more thing worth knowing: as of Windows 11 24H2 and Server 2025, Microsoft has signaled TxF is on the deprecation path entirely. If you're building something new that relies on it, stop. Use ReplaceFile or rename-based atomic writes instead. They work locally and remotely, and they won't leave you staring at 0x1A95 at 2 AM.