Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am accessing another computer on the network using a mapped network drive. The path looks like \\192.168.0.100\d$ which is mapped to my computer's "m" drive. I can access, view, create, delete, move, etc folders on this drive. However, some folders don't show up in windows explorer, even tho I can access them.

Example:

Lets say that M:\stuff\more_stuff is a directory.

What I can't do:

  • When windows explorer is pointed at M:\stuff I can't see more_stuff
  • In cmd prompt pointed at M:\stuff "dir" doesn't find more_stuff
  • In cmd prompt pointed at M:\stuff "dir /a" doens't find more_stuff
  • In python, os.listdir at M:\stuff doens't find more_stuff

What I can do:

  • Typing M:\stuff\more_stuff into the address bar lets me access the folder like normal.

Because there is no indication that this folder even exists, there could be more like them. I have no way of knowing how many folders are magically hidden on this mapped drive.

What are some steps I can do to figure out why this folder is hidden? (With the end goal of making it no longer hidden).

More info:

Accessing the drive through the map M:\stuff and the unc path *\192.168.0.100\d$* result in the same behavior.

Using windows search fails to see the folder.

In cmd prompt pointed at M:\stuff the command > del more_stuff does work.

Accessing the same drive from another machine with the same user account will show the folder correctly (at least in some cases).

Some users say they never experience this problem, and at least two users do experience this problem.

All of the users involved are local admins on the PC hosting the drive.

Restarting the affected machine doesn't fix the issue.

User1 and User2 are having problems seeing folders on this drive. So far any folder that User1 can't see neither can User2.

net use \192.168.0.100\d$ /delete doesn't help

Perhaps the Most Revealing Information So Far

User1 uses MachineA and has this problem. User3 has never had this problem. When User3 logs into MachineA, User3 experiences the problem.

Possibly Related

When accessing the drive like this \192.168.0.100\d$ the share runs as expected (minus the missing folder problem, but everything else is fine). While accessing the drive like this \192.168.0.100\d (no $, because d$ is shared as d) the share is incredibly slow. Explorer windows accessing the share hang for 10-30 seconds every time you change directories.

Playing With Shares

Okay now it gets weird. I shared \192.168.0.100\d$\stuff as e$. When I access \192.168.0.100\d$ or \192.168.0.100\d (notice no $) the more_stuff folder is missing. When I access \192.168.0.100\e$ the more_stuff folder is visible! So I mapped \192.168.0.100\e$ as a new drive, and more_stuff is missing again!

Share Properties

I accessed the share properties from Start > Right-click on "Computer" > Select "Manage" > Shared Folders > Shares > and found the following.

There are a handful of shares on this machine. One of those shares is "d$" mapped to "d:\" and when right clicked it says "shared for administrative purposes. Another one of the shares listed is "d" mapped to "d:\". When right clicked it brings up the normal properties. Is this a problem? Having two shares point to the same drive, one is "d$" and one is "d"?

share|improve this question

4 Answers 4

That's some strange_stuff.

Perhaps my imagination is failing me, but I can't think of anything that can hide a folder from a 'dir /a' command while leaving you with access to the contents of that folder.

First of all, try restarting the host and the client if you can. If that doesn't work...

You might have run in to some strange/corrupt permissions. Try accessing the permission of folder in question (M:\stuff\more_stuff) and see if they make sense. To do this, access the folder from Windows Explorer as you described and right click somewhere in the 'white' (not on a file), select properties / security. Make sure the permissions appear as expected.

If the permissions are somehow not what you expected, try resetting them by accessing the "Advanced" button under the Security tab and enabling the "Include inheritable permissions from this object's parent" option.

Should the behavior you're experiencing be related to permissions, you can reset all of the permissions for objects in the M:\stuff folder by modifying the permissions of M:\stuff and selecting the "Replace all child object permissions with inheritable permissions from this object" option. Careful, you'll lose any explicit permissions you've configured if you do this.

Two more thoughts:

  1. Run a disk check with the fix & recovery option selected on the host
  2. Check the host for mysterious 3rd party tools and viruses (just in case)

Best of luck!

share|improve this answer
    
Thanks for the reply. It's reassuring to know that I didn't miss something obvious. Whenever I remap the drive the problem goes away (until more folders are created). I'll keep an eye out for behavior and maybe I can narrow it down. –  Miebster Oct 2 '12 at 21:48
    
Two more thoughts based on your (@Miebster) comment: Under HKCU & HKLM \SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer on the host, check for the NoRemoteRecursiveEvents and NoRemoteChangeNotify and remove them (always back up first!). Alternately, check out the MaxMpxCT and MaxCmds registry values per UNC-based Caching Considerations. Either/both of these settings can result in lost SMB file change notifications if the provided values are too low. I'm banking on the first idea... –  Matthew Johnson Oct 3 '12 at 0:28
    
Okay, so sometimes disconnecting and remapping the drive does not work. I'm starting to suspect permissions since it tends to be the same folder each time. –  Miebster Oct 3 '12 at 15:44
    
I changed all of the permissions on the entire drive and it didn't seem to help. –  Miebster Oct 3 '12 at 18:53

Have you tried Windows Search for the folder to see if it shows up in a search? This would add some additional information either way that could be useful.

Edit: Also, have you tried accessing the same folder from a different user to see if it experiences anything different? This may help if we're dealing with a permissions issue.

share|improve this answer
    
Searching doesn't find it either, good idea. Same user, different machine, can see it. Different users can see it. More than one user is being effected though (so its not just something wrong with only 1 machine). –  Miebster Oct 3 '12 at 16:59
    
When the same user can see the folder from a different machine, is that machine in a different OU than the first machine? Are both machines joined to the domain or are you logging in via the security popup when you try to access the folder? Also, can you try setting up a network share of a folder inside d$ to see if that experiences the same problems as the root of the d:? –  Windows Ninja Oct 3 '12 at 17:45
    
All machines are on the same domain, there is only 1 authentication server. Lets say User4 doesn't have access to the drive but is logged in on MachineA. If User4 maps the drive it prompts for a password. If User4 enters User1's credentials, the problem occurs. Alternatively, if User1 logs into the machine, and then maps the drive (no password prompt since User1 has access) the problem still occurs. It doesn't seem to matter what user is logged in, or what user credentials are used to authenticate. The only thing that seems to matter is which machine is being used. –  Miebster Oct 3 '12 at 17:56
    
I shared a folder within d$, lets call it e$. When the user uses e$ they can see the missing golders. I'm wondering if its just masking the root cause (since this new drive had to be cached for the first time) –  Miebster Oct 3 '12 at 18:08
    
If you look at the share's properties do you get a popup saying it has been shared for administrative properties or does it just bring you to the properties window? To check: Start > Right-click on "Computer" > Select "Manage" > Shared Folders > Shares > Right-click the d$ share > Select "Properties" (note: you'll need to either do this from the local system or connect to it remotely via MMC). –  Windows Ninja Oct 3 '12 at 18:20

Removing certain entries from a directory listing (and the Windows API that provides such listing) is very common with root kits. If you know the name you can still delete it, but you can not list it in any way.

Maybe a root kit on MachineA coincidentally hides some things on that machine that has the same name as your missing directory.

What if you rename 'more_stuff' on the remote server to something else?

So I would test for a root kit on that machine.

share|improve this answer
    
Things are starting to get very weird, I'm running more tests, and will post more in the question. –  Miebster Oct 3 '12 at 19:27
up vote 0 down vote accepted

Thanks everyone for the help. This issue was particularly frustrating. After messing with the issue long enough I discovered enough clues that a local IT guy recognized the problem. I have no idea why this causes a problem but here is the scenario.

A drive is hosted as a share on MachineA running Windows XP SP 3.

The drive is accessed by MachineB running Windows XP SP 2.

For some folders (but not all) the first few files/folders (alphabetically) will not show up. "Not show up" means they can not be seen from explorer, cmd dir, cmd dir /a etc. They can be accessed by typing in the name (cmd cd name, or in explorer). The number of files/folders that don't show up can vary depending on the contents of the folder. I've seen 0, 3, and 4 (it will also change as you create new files in that folder).

For example, M:\stuff has 4 folders in it b, c, d, e. If this folder is suffering from 3 missing files/folders, the folder will only show e. The folders b, c, and d will be missing. If at this time the user creates a folder named a, folder d will show up and a will be missing.

The solution to this problem is to upgrade MachineB to Windows XP SP 3.

Of course, this doesn't help me, since MachineB is running Windows XP 64 bit which has no SP 3. I know of no other solution at this time. I will either move this machine to Win7, or just not use it to access shared drives.

share|improve this answer
    
In the future telling us what exact operating systems are on the machines in question upfront may save you a lot of headaches. I'm not sure I would consider this answer a solution as you awarded it, rather it is only a reason. –  Windows Ninja Oct 4 '12 at 2:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.