# Mapped Drive Not Showing? Here’s What Actually Fixed It

I set up a Group Policy Object (GPO) to map a network drive this weekend, but for some reason, test users weren’t seeing it after logging in.

Everything looked great — the policy was linked, no errors in Group Policy Management Console, and the correct OU was targeted. Still, the drive wouldn’t show up.

Here’s how I troubleshooted it in my lab and what actually fixed the issue.

## 1\. Check the GPO Scope and OU Placement

If the drive mapping is set under **User Configuration**, make sure the user account is in the correct OU where the GPO is linked.

**Tip:** OU structure matters — it’s easy to overlook which container your user is actually in.

## 2\. Verify Security Filtering and Delegation

In Group Policy Management:

* Go to the GPO → **Scope** tab
    
* Make sure the right users or groups are listed under **Security Filtering**
    
* Under **Delegation**, ensure they have both:
    
    * **Read**
        
    * **Apply group policy**
        
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1750027591692/32f827ba-8d18-4d8d-bc81-a8d291fd7b2b.png align="center")
    
    ## 3\. Use `gpresult` or `rsop.msc` to Confirm Application
    
    Run the following command on the user’s machine to see if the GPO is even applying:
    
    If it’s missing, the policy isn’t reaching the user at all — often due to filtering or OU issues.
    
    <mark>gpresult /r /scope:user</mark>
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1750027098213/77bcaf0c-0b37-48e2-a2fa-1f0acdc1a897.png align="left")

## 4\. Switch GPO Action from “Update” to “Replace”

By default, drive mappings use the **Update** action.

With **“Update,”** the GPO will only act if it detects a change in the mapping—for example, if the drive letter, path, or label has been altered. But if a user’s session has residual mappings from a previous logon or a policy hiccup prevents the drive from showing up, “Update” won’t intervene. It assumes all is well.

In my case, switching to **Replace** ensured the drive was re-created at every logon, which solved the issue.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1750027994822/cfb4b968-ae04-47d5-977e-ffcf3d2e49fb.png align="center")

## 5\. Double-Check NTFS and Share Permissions

Even with a perfect GPO, the drive won’t appear if users don’t have permission to access the folder.

Check both:

* **Share permissions** (right-click → Sharing → Advanced Sharing → Permissions)
    
* **NTFS permissions** (right-click → Properties → Security tab)
    

Make sure the target group has **at least Read** on both levels.

## What Worked for Me

In my lab, the issue turned out to be a combination of:

* GPO not scoped correctly to the user's OU
    
* Incorrect NTFS permissions on the shared folder
    
* GPO action needing to be switched to “Replace”
    

Once I adjusted all three, the drive showed up consistently at logon.

## Final Thoughts

Mapped drive issues seem simple — until they aren’t. I always recommend using `gpresult`, testing with a clean user account, and reviewing both OU placement and folder permissions as your first steps.

Let me know if you’ve run into this one too — it’s one of the most common (and frustrating) help desk tickets out there.