ERROR_REQ_NOT_ACCEP (0x00000047): Network Request Rejected Fix

Quick answer: ERROR_REQ_NOT_ACCEP (0x00000047) means the network request was rejected — almost always by share or NTFS permissions, a stopped service (Spooler/Server), or an SMB version mismatch. Fix the permissions and services, not the cable.

I've seen this pop up three ways: a user tries to map a drive to \\SERVER\Shared and gets a "network request not accepted" dialog, a printer install throws 0x00000047 midway through, or an app writing to a UNC path dies with a cryptic ERROR_REQ_NOT_ACCEP in the log. Every single time, someone blames the network. It's almost never the network. This error is Windows telling you the request reached the server (or the local spooler) and something on that end said "no." That's a permissions or service problem, not a cabling problem.

Had a client last month — small dental office, five PCs — where the front desk suddenly couldn't print to the shared Xerox. Nothing changed, they said. Turned out a Windows update had reverted NTFS permissions on the print share folder. Five minutes of fixing permissions, error gone. Classic 0x00000047 situation.

What ERROR_REQ_NOT_ACCEP actually means

Windows translates Win32 error 71 (0x47) into ERROR_REQ_NOT_ACCEP. In plain English: a request was sent to a network resource, and the resource refused to accept it. The refusal comes from one of these:

• Share permissions denying the user or group
• NTFS permissions on the target folder blocking write or modify
• Print Spooler service stopped or hung on the print server
• Server service (LanmanServer) not running on the host machine
• SMB version mismatch — old NAS box talking SMB1, hardened client refusing it
• Antivirus filtering SMB traffic and silently dropping requests

Notice a pattern? None of these are "the network is down." The network is fine. The endpoint is saying no.

Step-by-step fix

Work through these in order. Don't skip ahead — each step rules out the previous one.

1. Confirm it's permissions, not connectivity

   From the problem machine, run:

   ping \\servername
   net view \\servername

   If net view lists shares, the network's fine and it's a permissions or service issue. If it fails with "System error 5" or "53," you've got a different problem and should check DNS first.

2. Check the Server service on the host

   On the machine hosting the share (or the print server), open services.msc and confirm these are Running and set to Automatic:

   • Server (LanmanServer)
   • Workstation (LanmanWorkstation) on the client
   • Print Spooler if it's a printer error

   If Print Spooler is stuck in "Stopping," kill spoolsv.exe from Task Manager, then restart the service.

3. Fix share permissions first, NTFS second

   Right-click the shared folder → Properties → Sharing → Advanced Sharing → Permissions. Make sure the user or their group has at least Change. Then go to the Security tab and confirm NTFS rights allow Modify. Windows uses the most restrictive of the two, so both must be right.

   Common gotcha: everyone has Full Control on the share, but NTFS only grants Read to Authenticated Users. The app tries to write, gets 0x00000047.

4. Reset the print spooler if it's a print error

   Stop the spooler, clear the queue, restart:

   net stop spooler
   del /Q /F %systemroot%\System32\spool\PRINTERS\*
   net start spooler

   I've cleared jammed spoolers that had 400MB of stuck jobs. 0x00000047 instantly gone once the queue was empty and the service came back clean.

5. Check SMB version on older NAS devices

   If you're hitting a Synology, QNAP, or an old Windows Server 2003/2008 box, SMB1 might be the culprit. Windows 10 1709+ and Windows 11 disable SMB1 by default. Either update the NAS firmware, or if you must, re-enable SMB1 on the client (I don't recommend it — SMB1 is a security disaster).

   Check what's enabled:

   Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

6. Rule out antivirus interference

   Third-party AV with "network protection" or "file share scanning" features can silently reject SMB writes. Temporarily disable it and retry. If the error vanishes, add an exclusion for the share path or the server IP.

If that didn't fix it

Try these next. I've had to use every one of them at some point.

Clear cached credentials

Windows sometimes caches a stale credential for a server and keeps sending it after you've changed the password. Open cmd and run:

net use * /delete
cmdkey /list

Remove any entry for that server with cmdkey /delete:servername, then reconnect. Reboot after to clear the session cache properly.

Check the Windows Credential Manager GUI

Control Panel → Credential Manager → Windows Credentials. I've found old domain creds sitting there from a prior IT guy that were overriding everything. Delete anything pointing at the problem server.

Recreate the share

Rare, but I've seen shares with corrupted ACLs that no amount of permission-fiddling fixes. Unshare the folder, reboot, reshare it fresh. Sounds dumb; works more often than you'd think.

Check Event Viewer

On the server hosting the share, look at Windows Logs → System and Applications and Services → Microsoft → Windows → SMBClient. You'll usually see the actual rejection reason logged here — audit failures, permission denials, SMB negotiation errors.

Prevention

Two things keep this error away long-term. First, use groups for share and NTFS permissions, not individual users. When someone leaves or changes roles, you edit one group instead of chasing ACLs across ten folders. Second, document your print server setup and put the Spooler service under monitoring — a hung spooler is the #1 cause of 0x00000047 on printers, and it costs you nothing to catch it before users do.

One more thing: if you're still running SMB1 anywhere in your environment, plan its removal. It's the root cause of more weird share errors than any Windows update. Update the NAS firmware, migrate the legacy app, and turn SMB1 off for good.