WAD Cannot access mapped drive in 64b Win7

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
TCC 15.01.50 x64 Windows 7 [Version 6.1.7601]
TCC Build 50 Windows 7 Build 7601 Service Pack 1
Also tested in TCC-32

My laptop's drive is mapped as Z: on the Win7 machine. Its contents are accessible from Explorer.The drive letter does not appear in %_READY; %@ready[z:] returns 0. The mapping is verified by attempting to remap the same drive to the same letter, Win7 reports it is already mapped thus, override?

At the same time the Win7 drive is successfully mapped to the laptop, fully accessible.
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#4
TCC 15.01.50 x64 Windows 7 [Version 6.1.7601]
TCC Build 50 Windows 7 Build 7601 Service Pack 1
Also tested in TCC-32

My laptop's drive is mapped as Z: on the Win7 machine. Its contents are accessible from Explorer.The drive letter does not appear in %_READY; %@ready[z:] returns 0. The mapping is verified by attempting to remap the same drive to the same letter, Win7 reports it is already mapped thus, override?

At the same time the Win7 drive is successfully mapped to the laptop, fully accessible.

Not reproducible here -- and it cannot be a TCC issue. (TCC simply calls the Windows APIs for disk access.) It is probably an issue with your redirector.
 
#7
I had similar issues with mapped drives when running the 32-bit TCC v12 under 64-bit Win 7. In my situation, drives mapped in Windows Explorer were accessible in CMD (and vice versa) but not from TCC. They weren't even seen as existing at all to TCC. Similarly, drives mapped in TCC (via NET USE) were accessible to TCC but remained totally unacknowledged as existing to Explorer and/or CMD. I had to duplicate the mappings in TCC and WE/CMD if I wanted them to be universally available. It's as though they were two separate worlds that didn't talk to each other. I simply lived with that for a while.

For me, the problem seemed to disappear once I started running 64-bit TCC v15 but I can't swear that that was the only thing that made any difference. It was, however, the only part of the equation that changed. Sadly, you've already tried that so I guess this was a pointless post. I guess I just wanted to tell my little tale at the only place where anyone might not have been totally bored by it.
 
#10
Thanks all. I decided to turn off UAC, and that worked. What kind of contorted mind would set up a scheme where an "administrator", i.e., a user with all privileges, has "too many privileges" to access network drives?

BTW, I had earlier tried NET USE from my elevated TCC - it failed to find the laptop even while the laptop was uploading files...

What happened to the Personal Computer?
 
#11
Shortly after installing Win7, I wanted UAC off. I have come to consider it a good thing and recommend you leave it on.

After reading comments from Scott and (the) Dave I reproduced a known problem which may have been Steve's.

Logged on as vefatica (an admin, UAC on, restricted token) I mapped z: to \\lucky\d$. TCC and CMD could use the share. But apps started elevated (again TCC and CMD) did not know the mapped drive existed. I fixed that by adding
Code:
DWORD EnableLinkedConnections = 1 in
 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
and restarting (might have been sufficient to stop/start UAC???).
 
#12
Thanks all. I decided to turn off UAC, and that worked. What kind of contorted mind would set up a scheme where an "administrator", i.e., a user with all privileges, has "too many privileges" to access network drives?
It's not about "too many privileges", but rather, it's about security contexts, and limiting what a non-elevated application can do to influence the behaviour of an elevated application.

If mapped drives were done at the machine level instead of the user level, all I'd have to do is re-map my S:\ mapping, then ask my IT department to install some software for me, knowing that they'd hit S:\software-vendor\softwarename\software-installer.exe from an elevated session and launch my executable (which would then launch the real installer, so they don't get suspicious)

In a UAC context the attack surface is much smaller, but it's still safer to require re-mapping drives from each context.

I'm willing to accept that risk, so I use EnableLinkedConnections. A better approach is to simply not use mapped drives at all, and use the fully qualified UNC path every single time.

What happened to the Personal Computer?
Nothing at all; configure your computer the way you want. I'd suggest learning assembly to write your own OS from the bootloader up.</trolling>
 
#13
Nothing at all; configure your computer the way you want.
It's not quite that simple. There are some things you just can't do without turning UAC off (hoping I'm wrong and that someone knows better). I, vefatica, am an administrator. There's one thing I'd like to do seamlessly, namely set the system time. I'd need the SE_SYSTEMTIME_NAME privilege and AFAIK it cannot be obtained by an admin under a restricted token. My only option is to start some time-setting app elevated (and respond to the UAC prompt).
 
#15
I guess I just do not understand the philosophy behind the current UAC scheme. Once I log in as a user with all privileges, I ought to be able to do anything, access everything, using any and all of my programs. Conversely, I should be able to log in as a limited user, and have only specific privileges. In a multiuser file system there is also benefit to be able to control who can access what and how and when (e.g., by access control lists). But what is the benefit in a single user system?

"TheDave", you have a good example of why a multiuser system needs U(ser) A(ccess) C(ontrol). It does not apply for a personal computer - one which is for the exclusive use of a single person. Yes, in the business context the local computer is just a part of a distributed computing system, it is not a personal computer, just a more sophisticated and powerful terminal. Your example actually describes a method of sabotage or theft of resources which UAC can (hopefully) prevent.

Your suggestion to use UNC instead of drive letter mapping does not work if the same memory stick is plugged into a different machine of the network. With mapping (combination of NET USE and good old SUBST) I can make it appear on the same drive letter of all machines currently in the network, regardless of which port of which machine it uses. The UNC would not be the same. Yes, within TCC, I could use a directory alias, but not for external programs; all programs can deal with mapped drives.

Assembly? I spent many years writing in assembly language; on one real-time control system I even had to perform the task of assembler and linker manually, and write the punched tape loader, too - it was a totally bare system, no support software at all, just as you proposed... "An unknown product from a reliable company" was management's reason for the choice.

QUESTION: How can I map a network share to a drive letter so it is accessible by all programs from TCC? I attempted with net use, but the response was "access denied" - executed from an elevated TCC session, but with UAC disabled. Starting Windows Explorer from the same TCC instance (without using start /elevated) allowed me to successfully map.
 
#16
When an admin logs on he gets a limited token (in many senses, though not all, better than an ordinary user's token). There are some things he can do seamlessly (no UAC prompt) ... some with a UAC prompt ... which ordinary users can't do at all. One big purpose of this is to prevent an admin from shooting himself in the foot (even inadvertantly). For example, if you had full-blown privs, a web page could do nasty things.

There's a pretty well-know way to run something elevated without the UAC prompt, but with UAC on. Make a scheduled (run-on-demand) task ... to run with the highest privs (say for RegEdit or TCC) and then make a shortcut (TCC alias, or other) to run
Code:
schtasks.exe /run /tn <task name>
I have global hot-keys for both RegEdit and elevated TCC ... rarely use them.

As for your question ... I have no such problem. I am an admin running under UAC and, with TCC,
Code:
v:\> v:\> net use z: \\lucky\d$
The command completed successfully.
All apps can see/use z:. I don't recall any special actions required to make it behave this way. There is a service responsible for spreading knowledge of new network events. Did you monkey with the services at all? Whenever I try to google this I always arrive back at some "EnabledLinkedConnections" discussion (which I gather is not your problem).

In general, roaming around in SECPOL.MSC can be educational.