There has been some spirited discussion within our IT department about mapping network drives. In particular, it has been said that mapping network drives is a bad thing and that adding DFS paths or network shares to your (Windows Explorer/Libraries) favorites is a far better solution.

Why is this the case?

Personally I find the convenience of z:\folder to be better than \\server\path\folder', particularly with cmd line and scripting (of course I'm not talking about hard-coded links, naturally!).

I have tried searching for pros and cons of mapped network drives, but I haven't seen anything other than 'should the network go down, the drive will be unavailable'. But this is a limitation of any network-accessed storage.

I have also been told that mapped network drives poll the network when the network resource is unavailable, however I haven’t found more information on this. Do network drives poll the network any more than a Windows Explorer library/favourite? Wouldn't this still be an issue with other network access mechanisms (that is, mapped Favourites) whenever Windows tries to enumerate the file system (for example, when a file/folder picker dialog is opened)?

  • 13
    I don't think there's any real reason other than superstition and personal opinion, for the reasons you've stated. (So I think this is a bad question for subjectivity reasons) – Shinrai Feb 23 '12 at 23:51
  • 9
    Mapped drives are supported on Windows Server 2008 R2 in the Group Policy Editor, so I would venture to say that it's personal opinion only preventing this. – user3463 Feb 23 '12 at 23:55
  • 3
    @Shinrai - Thanks for the reply. I'm looking for technical reasons rather than personal opinion - as I'm unaware of any - so I hope that's not considered subjective. I assume it's all the same mechanics under the hood anyway and just presented differently to the user. – Beeblebrox Feb 24 '12 at 0:02
  • 4
    @foocode - I am in complete agreement with you, I think they're just being silly. The only possible objection I can think of is that some poorly written software might treat them as local drives, in which case why are you using that software? They're just superstitious, you do whatever the hell you want. (Personally I don't map my drives but that's just me) – Shinrai Feb 24 '12 at 0:08
  • 1
    Some of that poorly written software (accounting software comes to mind) is demanded to be used by certain firms/clients... – LawrenceC Feb 24 '12 at 2:29

20 Answers 20


I imagine the strongest reason for not mapping network drives is that the admins don't want to deal with the headaches of maintaining an index of a finite number of drive letters in addition to the network paths. For one, there might be too many commonly-used network shares to assign drive letters to all of them, and in a large organization, not everyone will have access to all the same shares. Share names are also more descriptive and potentially less ambiguous than drive letters (more on the ambiguity later).

Second, you can run into drive letter collisions. If someone's PC has a memory card reader, that might gobble up four or more drive letters. A and B are typically reserved for the floppy drives of last century, and C and D are usually reserved for the hard drive and optical drive, so the card reader will use E, F, G, and H. If one of your network drives is usually mapped to H: via a logon script, this poor person either won't be able to use the card reader's H: drive or won't be able to mount the network drive.

Unless someone within the organization is responsible for allocating drive letters for specific purposes, the network drives could also end up causing a lot of confusion. For example, suppose you map drive S: to the share that has the setup programs for all your site-licensed software, and someone else maps S: to the shared drive where they drop all kinds of shared documents. When you try to explain how to install some software, you tell them to open their S: drive and find the setup program for Microsoft Office, but all they can find is a folder named office, which contains a bunch of miscellaneous files someone dropped there for a temporary file transfer. It might take you 5 or 10 minutes to sort out the confusion.

There are also some potential performance issues if a server goes down or if a machine is taken off the network. For example, if you map network drives on a machine, then remove the machine from the network (maybe it's a laptop), the machine may appear to hang upon logon while Windows tries in vain to mount the missing network drives.

On the other hand, on older versions of Windows, I've noticed that file transfers to or from a mapped network drive often go much faster than if you browsed to the network folder and performed the same file transfer--in which case, most people would prefer to map network drives.

  • Thanks for the input. I imagine the existing 'rule of the land' re: no mapped drives is to stop the user base causing these very issues. – Beeblebrox Feb 24 '12 at 3:39
  • 22
    +1 for the confusion caused by different users mapping drives to different places. I've been told by users many times that they are putting a file on the "Z:\" drive and having to spend a age figuring out where their particular Z drive is mapped. Not a technical issue perhaps but it can definitely be an organisational issue. – Steve Homer Feb 24 '12 at 8:38
  • I've marked this answer as the Accepted Answer because it covers root operational/practical aspects of using mapped drives rather than specific cases (i.e. dependancy issues) and theoretical downsides (i.e. the great security-related discussion above). Thanks @rob! – Beeblebrox Feb 25 '12 at 1:52
  • 4
    Another huge drawback is that once you start down this road, any emails links that reference the "Z" drive will break if you remove the mapped drives. Another severe drawback is files that span multiple files(such as CAD files) will totally break if the mapped letter is removed! This is due to the dependency files being loaded with a drive letter, rather than a UNC path. We are stuck with them at my company due to these very issues. The negatives far outweigh the 'convenience' factor of saving a few mouse-clicks. – Lee Harrison Jan 29 '14 at 13:41
  • 1
    It is already mentioned that it gets confusing fast if nobody is resposible for allocating drive letters, but I would like to mention that in the case that drive letters are actually allocated centrally, they can be very convenient. Simple example: Everyone can access their private fileshare via drive M, the company wide general fileshare via drive N ... and all project folders are located in drive P. -- However, it should be noted that this practice is most usefull when there is a limited number of drives that simple users need to access. Else they have to learn to work with 2 systems. – Dennis Jaheruddin Oct 28 '16 at 13:54

The simple answer is that it isn't a bad thing. Network drives are perfectly safe to map as drives.

The superstition comes from the fact that you shouldn't be mapping foreign (i.e. Internet) drives as local because files opened from mapped drives are opened using the "local" zone, which generally affords them less protection - and if the files are actually coming from the Internet this is a reduction in security.

If, as I suspect is the case, you're actually mapping int​ra​net network drives, then opening the folders as mapped drives is exactly as secure as accessing them via their network path names. The only difference is that having them mapped is more convenient.

  • This is a very good description on the security matters associated with mapping. Thanks for the contribution! – Beeblebrox Feb 25 '12 at 1:49
  • A situation where network shares are not perfectly share to map as drives is if you are running an automated job. The mapped drives are loaded with the account's profile. If the user's profile is not loaded, then those mapped drives will not exist. – Ian Boyd Dec 19 '13 at 19:10

In my experience, it mostly centers around badly written software.

If person A works on a suite of files that are mapped to G:, and then person B tries to open the same set of files with the same path mapped to H:, things fail.

If you use UNC paths, then assuming that person A and person B's computers can both see the share point, everything will work fine.

Sure, the ideal solution is to use software that doesn't store file relationships using absolute paths, but that's not something you can always control.

A lot of software in the CAD/CAM markets is poorly written, and barely works at all. Since the market is rather small, there is little competitive pressure. I know at least one piece of software that has had issues with absolute paths for the last 5 major releases, and they still remain unfixed, despite reporting the problems to the company.

  • 1
    "the ideal solution is to use software that doesn't store file relationships using absolute paths" - most commonly, the problem is people not programs who do this. – MSalters Feb 24 '12 at 10:41
  • 2
    @MSalters - Tell you what. You convince the entire software industry to rewrite large portions of their software. – Fake Name Feb 24 '12 at 10:45
  • 1
    @Fake Name, I think he means the users using the programs. I.E. Putting a link in the document H:\mystuff rather than \\myserver\\mystuff – Dalin Seivewright Feb 24 '12 at 15:48
  • 3
    @Dalin Seivewright - That seems to assume that you can manually set the link at all. In a lot of the software I have seen, if the main document is in H:, the related documents will be automatically stored using H: whether you want them to be or not. – Fake Name Feb 24 '12 at 22:16
  • 2
    @CADbloke - Nope! It's Altium Designer. I'm pretty sure behaviour like this is pretty much rife in the specialty software market. – Fake Name Feb 18 '13 at 9:50

We've had serious problems with network drives where I work because sometimes Windows doesn't connect to them, and it seems to not automatically connect a network drive when a program tries to access it.

At least half a dozen times a user from accounting has called because she gets the same error. It's because she opened program X, which is using a file mapped on network drive Y:, and it's not connected for some unfathomable reason.

  • 1
    That sounds like a real pain. Would that commonly found to be user error i.e. the drive was initially mapped by an admin account so requires different permissions, or the 'automatically map drive on restart' was left unticked? I have only ever had issues when I've disconnected from a drive and then tried to reconnect. It would claim I had more than 1 open connection. Could have been a SAMBA issue though. – Beeblebrox Feb 24 '12 at 10:55
  • 2
    @foocode I'm not sure about the first (but the user does have permissions) and the drive is set to connect on start up...it just takes a while. As in minutes. Sometimes it only connects when you manually access it in windows explorer which is, unfortunately, what I had to teach the user to do. – Ben Brocka Feb 24 '12 at 14:19
  • @BenBrocka I've also experienced this problem. For some unknow reason it takes very long time for Windows to reconnect mapped drives on startup. – user555 Jul 10 '13 at 15:45

I doubt that the IT guys are worried about one user mapping a network drive, rather they are worried about a hundred users or a thousand. For example, if a bunch of hosts kick off search indexing of a networked drive or drives at the same time, how will that affect everyone else trying to use the network? When a networked drive is inevitably taken offline, will it lock up hundreds of machines until the OS gives up and drops the drive mapping? Will PCs hither and yon boot more slowly or fail to boot altogether if connections to mapped drives can't be reestablished?

  • This line of thought certianly brings different non-technical elements in to the equation. Proper planning by IT is needed to avoid the issues you've raised. If it helps, for the particular scenario I've based my question upon, users aren't able to install programs or modify application settings. I'm hoping the question is more 'what would be the best option from a technical point of view; a library/favourite or a mapped drive' in terms of easing access to a network share. – Beeblebrox Feb 24 '12 at 0:53
  • But yeah, what you've mentioned would suck. :) – Beeblebrox Feb 24 '12 at 0:56
  • 2
    This is the only reason that comes to mind: mapping the drive means that Explorer will throw a fit if it can't find it. Even opening Explorer when you have 3+ network drives mapped can really slow it down. – styfle Feb 24 '12 at 6:59
  • 1
    Drive mappings are logonsession-specific as of Windows XP, so they wouldn't slow down the boot process. And AFAIK, if a network share is taken offline while being accessed, it will affect the clients the same way regardless of whether it is accessed through a letter or UNC path. – user1686 Feb 24 '12 at 22:06

One problem with the \server\dir syntax is that command windows cannot cd to them. If you have admin privileges and do not want to use a drive letter you can use the mklink command to mount drives to a directory instead of a drive letter. The directory Home should not exist.

mklink /d "c:\Drives\Home" "\server\HomeFolder\user1"

This folder is useable by everything.

Mounting to a drive leter could be bad because it is possible for it to change to another mount point. Then you are reading and writing to something you don't expect. If executables from a mount point change, they could contain viruses.

My solution requires admin privileges, so if you are not running with admin rights, it is more secure since another program could not change it on you without admin rights.

  • 3
    Clarification; 1.Windows Batch cmd.exe gives the error "CMD does not support UNC paths as current directories." ; 2.Windows Powershell supports "set-location myUNCpath" just fine. – AnneTheAgile Jun 10 '15 at 18:53

Here's one good reason:

Windows (at least XP) does not support file paths with over 256 characters. Mapping allows someone to add a file where otherwhise wouldn't be possible, by shortening the path. Then you have a program that navigates through all files and folders, and is not aware of the mapping. Without the mapping, the existing file has a path length above 256. The program crashes.

  • 2
    Good programs do not crash outright whenever they fail to open a file. If they did, it would create many problems in a domain environment where files are restricted by ACLs. (Also, technically, Windows can support paths up to approx. 32767 Unicode characters, if the `\\?` prefix is being used.) – user1686 Feb 24 '12 at 22:03

A number of pieces of software, including various version of Microsoft Visual Studio and CMS Bounceback, will only work with drive letters and not with absolute paths. Given this restriction then to use any such software requires you do define drive letters - you have no choice. But Windows does not make this very easy as it seems to ask for a user ID and password, but only one user ID and password is allowed in Windows for all connections to any one network device (e.g. multiple disks and printers).

  • 1
    This is common in cross-platform dev software too. For example, Intellij/PhpStorm don't support Window's UNC paths so mapped drives are the only non-local drive option. Of course there's FTP too but that's not as quick. – Beeblebrox Sep 18 '13 at 1:29

Just talk to some of the hundreds of IT consultants who are now having to deal with the recent Zero-day outbreak of "CryptoLocker" and you'll soon realize that mapped-drives on a local computer that get's infected can cause massive damage to data on the server, via the mapped drive.


“CryptoLocker will also access mapped network drives that the current user has write access to and encrypt those. It will not attack simple server shares, only mapped drives.”

Thus, there are clearly security concerns with using mapped drives in this age of ever-present and newly discovered zero-day malware hitting users frequently.

We've eliminated all mapped drives across our LAN and use "network shares" instead.

  • 9
    It's only a few more lines of code to enumerate all local servers and all available shares on them. So just because the current versions don't affect shares, it doesn't mean you are safe, just because you don't map drives. – Peter Hahndorf Nov 1 '13 at 17:20

A few reasons not to use mapped drives:

1) They take up resources on both the local machine with the mapped drive and the network resources. Local applications can become sluggish because your local computer has to read the contents of the mapped drive when the application is launched or when the system is booted. Try it out. Map a bunch of drives and launch Excel. Unmap the drives and try it again.

2) Moving your application to a new environment will be tedious. In the event of a disaster recover, moving to a more powerful machine, or if another developer is taking over your application. If the new environment doesn't allow mapped drives or drive letters are mapped differently then someone is spending time rewriting code. The time saved on the front end will be more than lost fixing it.


I know it's an old thread, but I wouldn't say they are perfectly safe. We removed mapped drives because of the security risks. Many viruses try to spread across drives. They do not however, spread across shortcuts pointing to DFS shares. Something to keep in mind...

  • 2
    At least until enough people make the switch, then so will malware coders. – user66001 Dec 28 '15 at 4:01

One reason for limiting drive mapping would be e-mail viruses (zip or exe files opened by somewhat "dense" users) such as Cryptolocker which will alphabetize all files on local and mapped drives and encrypt them. It (in particular) does not discriminate according to drives. We got hit, and were able to recover using backups of the server(s), but of course the local files were "toast".

  • 1
    Am sure malware coders will start enumerating "added" network shares if people start using them in favor of mapped network drives. – user66001 Dec 28 '15 at 3:57

Certain widespread viruses and malware will exploit mapped drives. That's about as good a reason as any not to use them.

  • 1
    At least until enough people make the switch, then so will malware coders. – user66001 Dec 28 '15 at 3:54

Mapped drives are faster if you are manipulating large quantities of files. Windows authenticates your access once with a mapped drive, and then allows the file interactions to take place. UNC paths are authenticated by Windows for every file accessed. So the authentication process would happen thousands of times if you were manipulating thousands of files under a UNC path. Mapped Drive - Authenticate once UNC - Authenticate every time a file is accessed.

This can have implications with something as simple as copying files. Mapped drives will always be faster; noticeably with large numbers of files.


In relation to the crypto/ransomware considerations, Locky is one example of ransomware that can spread via UNC paths as well as mapped drive letters. If your concern re: mapped network drives vs. UNC paths is determined by the potential for ransomware attacks, understand that it only protects against some.

There are several ways to go about detecting/preventing ransomware attacks - and it is generally recommended to use multiple protection methods: protect the network, protect the endpoint, and maintain a robust backup regime. I personally use Sophos InterceptX as an anti-ransomware solution on the endpoint, a Cisco ASA (with IPS) firewall, ShadowProtect for backup and use mapped network drives where it makes administrative sense to do so.

Disclaimer: I'm a Sophos Certified Architect. Though I don't work for Sophos, I think their technology is neat. I also work for an MSP, and that's the technology we decided upon after checking into the various options available in Australia.

Edited as requested to give more information for the second paragraph. Also, I speak Australian, not English, grammar is slightly different and some words are spelled differently (it's Colour, not Color, and don't even get me started on cantaloupe).

  • The question asks "why". The first paragraph addresses that. The second paragraph is just product promotion that doesn't address anything asked in the question. Technically, it isn't spam because of the disclosure, but it makes the answer very spam-like. The answer is in a review queue, which means it will get some scrutiny, and people are likely to object to its promotional nature. Consider editing out the second half of the answer. – fixer1234 Jan 3 '17 at 7:23

I do not like to use mapped drives because I use a variety of network resources infrequently and I can never find the complete address for others to use. Using shortcuts also enables me to step up in the directory with ease. If the only reason to map drives is the 256 character limit, that is a sorry excuse to loose all that file location detail.


Mapped drives are dangerous! In the past few years with the surge of ransomware, I have been removing mapped drives wherever possible. Ransomware targets all DRIVE LETTERS not just local data. So while you are safe as long as you keep redundant backups, it is still a headache to have to deal with such a data breach.

If you are in a business environment (primary target of ransomware), and if you can, get rid of mapped drives!!

  • 2
    Alternatively you could work to prevent infections in the first place... – Burgi Feb 22 '16 at 14:18

Certain ransomware viruses, such as the CryptoWall family, look for any mapped drive and infect those drives. If the network share is using UNC however and not a drive letter, then these viruses do not infect the share.

  • 1
    At least until enough people make the switch, then so will malware coders. – user66001 Dec 28 '15 at 3:59

Network drive is a good way to share resources, but I don't agree with the fact that home directories be put on a sharable network drive. That's just blatantly stupid. Most applications use your home directory as place to store specific application settings for users. If IT want's one more headache (as if they don't have enough to deal with), then fixing application dependencies for users within the network can be a pain they can add their bag of problems. This issues can mount in an environment where many such applications are used and their dependencies and requirements change. For one thing work can be stiffled for users on the network and company lose money and time based on low productivity levels. That is something that cannot be risked. Secondly, some organizations map user home drive on the network to monitor what's on there. The government does that a lot as part of their requirement. It also adds to the problem of being able to work from home. If your connectivity via VP has issues with your application working remotely through a VPN session, where you run your application that requires a dependency from your network mapped home drive and the drive mapping fails, then you're hosed.

Personally, I think it should only be done for good reasons, but not to the point where it hinders productivity and affects the company's bottom line.


The number 1 reason you would not want to do this is that ransomware can not access a UNC path, but drive letters are fair game. If you would like you network share cryptolocked then by all means continue with drive letter mapping.

I personally do not see the advantage of drive letters and truly find the UNC paths are easier as I never have to worry about mapping drive letters, especially after changing login passwords. You can create shortcuts which behave no different than drive letters and can add those shortcuts to Windows Explorer.

  • 4
    "Ransomware can not access a UNC path" - please provide some evidence for this claim. – DavidPostill Mar 22 '16 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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