Is it bad to map network drives in Windows?

Question

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.

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)?

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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.

Solution 5

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?

View more solutions

Comments

[Admin]

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)

[Admin]

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.

[Admin]

@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.

[Admin]

@RandolphWest - Thanks, didn't know about that one.

[Admin]

@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)

[Admin]

Some of that poorly written software (accounting software comes to mind) is demanded to be used by certain firms/clients...

[Admin]

UNC paths are better because you avoid issues with conflicting drive letters, as mentioned. DFS-based UNC paths are better still, because they are abstracted from specific server names.

[Admin]

@JeffSacksteder DFS is already implemnted here and works well. Just the file paths can still be very long! Hence the desire to map one of the oft-used nested shares to a (client) top-level mapped drive.

[Admin]

@Shinrai - 'poorly written software treat them as local drives' - this would include Adobe Acrobat as the updates for that have a fit if you are using a mapped network drive for your 'My Documents' folder... Easy solution was to change a registry entry to the UNC patch but still! Idiot programmers! ;)

[Admin]

When I last used Windows regularly (Win 2000), logon could take ages if you had persistently mapped a network drive that wasn't accessible (e.g. when I brought my work laptop home). I seem to recall cutting the time between entering my password to the desktop becoming usable by around 2 minutes by unmapping shares. This issue has probably been fixed though at some point in the past 13 years...

[Beeblebrox]

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]

But yeah, what you've mentioned would suck. :)

[Beeblebrox]

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.

[styfle]

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.

[Steve Homer]

+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.

[MSalters]

"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.

[Fake Name]

@MSalters - Tell you what. You convince the entire software industry to rewrite large portions of their software.

[Beeblebrox]

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.

[Ben Brocka]

@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.

[Admin]

@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

[user1686]

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]

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.

[Fake Name]

@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.

[Beeblebrox]

This is a very good description on the security matters associated with mapping. Thanks for the contribution!

[Beeblebrox]

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!

[CAD bloke]

That one piece of ... software is probably AutoCAD. See also here for AutoCAD & physical network problems. Autodesk's official stance is that they DO NOT support editing files on a network share. That's because they can't make it work. See also this forum thread

[Fake Name]

@CADbloke - Nope! It's Altium Designer. I'm pretty sure behaviour like this is pretty much rife in the specialty software market.

[CAD bloke]

Oh yeah, you should see the state of specialty broadcast software. Some of it even only runs on a specific BIOS version... in Windows 2000. People pay money for that. A lot of money. btw +1 for identifying the ubiquity of UNC paths. That's a good point.

[Fake Name]

@CADbloke - For what it's worth, (and because I actually really like Altium), they're probably the only EDA package on the market that is actually trying really hard to modernize their software, and they have made tremendous improvements in the last few releases. Some software (Cadence Allegro) can't even handle spaces in the executable path!

[Beeblebrox]

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.

[Peter Hahndorf]

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.

[Ian Boyd]

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.

[Lee Harrison]

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.

[Job AJ]

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.

[user66001]

At least until enough people make the switch, then so will malware coders.

[user66001]

Am sure malware coders will start enumerating "added" network shares if people start using them in favor of mapped network drives.

[user66001]

At least until enough people make the switch, then so will malware coders.

[user66001]

At least until enough people make the switch, then so will malware coders.

[Burgi]

Alternatively you could work to prevent infections in the first place...

[DavidPostill]

"Ransomware can not access a UNC path" - please provide some evidence for this claim.

[Dennis Jaheruddin]

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.

[fixer1234]

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.

[Joshua K]

In our operations, we have encountered every challenge described in this answer.

[Mike Lowery]

It's still a problem in Windows 10.

[Mike Lowery]

Is this really true? I believe in both cases credentials are cached on the client. The question is whether or not they're resent to the server for each request and what kind of performance hit that produces.