I am having an issue where a shared network drive cannot be accessed by a couple users. I am one of the ones that cannot access it, and I noticed when I checked the properties of my shared drive that it is showing a RAW file system. On another users pc who can access the drive with no problem, they are showing NTFS file system. I am the network administrator, however we both have admin rights to the network and our own pc. I have checked the settings for both myself who cannot access the drive and a user that can, and we are both setup the same. I have also compared two drives on the server, one I can access and the other I cannot, and do not see any difference there either. Can someone please tell me if this may have something to do with the NTFS vs RAW, and what I can do to fix this problem? Both of our O/S is xp.
Dani AI
As explained, Windows can keep stale volume identities that lead to one client misidentifying a server volume while others see it correctly. That registry-based cleanup is one fix, but it should be a last step. The checklist below covers safer, higher-probability checks first and gives fallbacks if the problem persists.
Start with server-side verification. Confirm the volume is healthy on the server console (Disk Management) and that the share actually points to the expected folder on that volume. Look in the server Event Viewer for "Disk" or "Ntfs" errors and run an offline chkdsk from the server if any filesystem errors appear. Also confirm there is no DFS/replication or drive-letter/volume aliasing that could make different clients hit different underlying volumes.
Check share and NTFS permissions separately: both must allow access. Verify both clients are connecting to the same UNC path (same server name/IP and share name). Differences in hostname vs IP or cached credentials can cause one client to be authenticated differently, producing access failures even for admin accounts.
On the client side, remove and remap the network connection, clear cached network credentials and any Offline Files cache, then reboot that client. Useful quick commands:
net use \\server\share /delete
net use * /delete Use those with care (they remove mapped sessions).
If the issue still shows only on a specific client, consider a controlled registry cleanup as suggested (back up the registry first and create a restore point). Alternatively, create a temporary new share name pointing to the same folder to force Windows to build a fresh association. If filesystem corruption is confirmed on the server, restore from backup rather than forcing repairs that might risk data.
This arises because Windows remembers all removable storage devices connected to it, the reason being that it tries to keep track of the file structure that it used when it accessed that device last. Windows cares nought for the drive letter or the drive name you give because you can change them at will and confuse Windows, so it associates the persistent volume name with unique volume identifiers and disk signatures..
This is the key you need: HKLM/System/Mounted Devices
Identify your device at \Dos Devices\"its drive letter": and delete it [delete that name]
It will also occur up the page as one of the \??\Volume {....} entries. To find which one you will have to rclick on each, select Modify and read the upper part of the ASCII interpretation to identify the drive [the remainder of that ASCII is the unique identifier]. Until you find the correct one... then delete that name also.
Restart your machine, the drive will/should be re-associated, perhaps correctly.
This is why if you plug in a drive to your firm's computer and do something really naughty then you had better get rid of that drive afterward. Its unique identifier is stored, plus what was on it.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.