Fix printer error 0X00000A75: can't remove last server share

The 30-second fix: Check if it's actually a printer issue

Before you go digging into DFS namespaces, confirm you're not wasting your time. What's actually happening here is that Windows won't let you remove a printer share that's the only target left for a DFS root or link. But often the real trigger is a stale printer driver or spooler lock — not DFS at all.

1. Open Services.msc (Win+R, type services.msc).
2. Find Print Spooler. Right-click, select Stop.
3. Leave it stopped. Try deleting the printer share again via Devices and Printers → right-click the printer → Printer properties → Sharing tab → uncheck Share this printer.
4. If it works, restart the spooler. You're done.

If the share still won't budge and you're staring at that 0X00000A75 error, the issue is DFS. Move to the next section.

The 5-minute fix: Remove the DFS link from the namespace

The reason step 1 fails is that Windows sees the printer share as a DFS target — it's literally linked into a namespace like \\domain\dfsroot\printers. To unlink it, you need admin access to the DFS namespace server.

1. On a machine with DFS Management snap-in (usually a domain controller or admin workstation), open dfsmgmt.msc.
2. Navigate to the namespace containing your printer share. Look for a folder or link that points to the printer share path (e.g., \\printserver\PrinterName).
3. Right-click that DFS link → Remove link from namespace. Confirm the warning — this only removes the DFS pointer, not the share itself.
4. Go back to the print server. Now try removing the printer share again. Should work immediately.

This fix works 90% of the time. But sometimes the link removal itself fails with the same error. That's when you need the advanced approach.

The 15+ minute fix: Clean DFS metadata manually

What's actually happening here is that the DFS namespace has a stale or orphaned link — it thinks the printer share is still a target, but the namespace's own cleanup routines can't delete it because the link metadata is corrupted. You'll need to use dfsutil to nuke it from the command line.

Step 1: Identify the link

Open a command prompt as Administrator. Run:

dfsutil /view /root:\\domain\dfsroot /dir:printers

Replace \\domain\dfsroot with your actual namespace path. This shows all links under the printers folder. Look for the one pointing to your problem printer.

Step 2: Remove the link with force

dfsutil /remove \\domain\dfsroot\printers\PrinterName /immediate

The /immediate flag tells DFS to skip the usual grace period and remove the reference from the root immediately. If this still fails with 0X00000A75, the metadata itself is corrupt.

Step 3: The nuclear option — delete the printer share from the file system

If the CLI also fails, the DFS link is hanging in the namespace's PktPrivate table. You can clear it with ADSI Edit, but that's risky. Safer: rename the printer share on the print server to break the link.

1. On the print server, open Computer Management → Shared Folders → Shares.
2. Right-click the printer share → Stop Sharing. If it errors out, skip to step 3.
3. Open a command prompt as admin on the print server:

net share PrinterName /delete

If net share fails, you'll need to restart the Server service. Warning: this disconnects all file shares temporarily.

net stop server
net start server

Then immediately retry the net share PrinterName /delete command. This works because the Server service reloads share metadata from registry, and the DFS lock is released.

Step 4: Clean the DFS namespace again

Now go back to the DFS management console or CLI and remove the orphaned link — it should complete without the error.

Why this error happens in the first place

DFS (Distributed File System) allows you to create a single namespace where multiple servers host the same share for redundancy. When you share a printer, Windows automatically registers it under the DFS namespace if the print server belongs to a DFS root. The error 0X00000A75 is Microsoft's way of saying: "This share is the last target for this DFS link — if I remove it, the link becomes useless." But the sanity check is buggy: it fires even when you're okay with breaking the link.

I've seen this most often on small office networks where IT admins share a printer from a domain member server that's also a DFS namespace server. The fix isn't intuitive, but the sequence above covers it from easiest to most invasive.

One last thing: if you're on a home network with no domain, you won't hit this error — DFS requires Active Directory. So if you're seeing 0X00000A75 on a standalone machine, check the spooler fix first. Something else is corrupt.