Problem when copying from network mapped drives

[MarcinW]

Steps to reproduce (TC 9.12 RC4, tested on Windows 7 64-bit):

1) Proper behavior: Try to copy some file from local drive to system directory (most probably "C:\Windows\System32"): an "As Administrator" dialog is displayed, and then the file is properly copied.

2) Improper behavior: Try to copy some file from network mapped drive to system directory (most probably "C:\Windows\System32"): an "As Administrator" dialog is displayed, and then TC fails with "Access denied" message.


Possible cause: when trying step 2) by using Explorer instead of TC, a warning window appears, which tells something like "Internet settings suggest, that at least one of these files may be malicious. Do you want to use it?".

It seems that TcmAdmin should handle this case somehow. As a temporary solution, the remote file could be copied to some local temp directory, and then to the destination directory.

Regards

[Dalai]

The reason is that network drives are user-specific. Or rather they're bound to a user token. Since the administrator token is different from the user token, the TC admin tool will not be able to find any network drive because it's not connected. This could be circumvented by passing the UNC path to the TC admin tool instead (there's an API function to "convert" network mapping to UNC paths). Still, one case remains that can't be solved at all: when the admin (token) is not allowed to connect to the UNC path, but the user (token) is.

Regards
Dalai

[MarcinW]

You explained this nicely :)

Still, one case remains that can't be solved at all: the admin (token) is not allowed to connect to the UNC path, but the user (token) is.

Well, when I map \\Laptop\SomeDir as R:, then I cannot copy from R: to Windows directory, but I can copy from \\Laptop\SomeDir to Windows directory... So, according to my tests, passing UNC pah to TcmAdmin would work.

Regards

[Dalai]

Yes, that's what I meant. I edited my post above to make it more clear which case can't be handled.

Regards
Dalai

[MarcinW]

Ok, It's clear now.

BTW, even the case, when the user token can access a network share, but the admin token can't access it, can be handled - TC could read a file from the network share and use some interprocess communication to pass file's contents to TcmAdmin (by pasing blocks of shared memory, or even by using a temporary file).

So:
- a quick fix is to covert mapped drives to UNC paths before passing them to TcmAdmin,
- a full fix is to add also some interprocess communication between TC and TcmAdmin, for cases where TC can access a network share but not the Windows directory, and TcmAdmin can access the Windows directory, but not the network share.

Regards!

[ghisler(Author)]

On Windows Vista and newer, network drives are mapped separately for each user. Running a program "As admnistrator" is treated like a separate user. To fix it, you can tell Windows to grant access to all users of the PC:
1. Run regedit.exe
2. Go to the following key:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System
3. Right click in the right panel, and create a new DWORD entry with the name
EnableLinkedConnections
4. Set the value to 1
5. Restart your computer

Unfortunately there is a bug on Windows 8 and 8.1 (and maybe also in 10): If a normal user creates a mapped network drive to a subfolder like \\server\share\subfolder, the elevated user will see the drive, but it points to \\server\share instead of pointing to the subfolder. Therefore just create mapped drives to shares (by sharing the right folder directly).

[MarcinW]

Thanks for your detailed explanation.

So - as far as I understand - enabling EnableLinkedConnections allows TcmAdmin (i.e. admin user) to see network drives, but this doesn't work properly on Windows 8 and above.

But making a small change in TC - i.e. converting mapped drive into network path before passing this path to TcmAdmin, as Dalai suggested, would solve the problem for all Windows versions, and no configuration changes (i.e. EnableLinkedConnections) would be needed then.

Regards

[Dalai]

I second Marcin's statement. Why require users to make a global change to their system (with possible side effects) when you can work around the issue at hand in TC itself? Even worse: What's with TC used in domains? Are the users supposed to change this GPO there, too? Yeah, I know, domains should have strict privilege separation.

There's also a discussion in this GPO on Serverfault. A comment on an MS Technet article about this subject also mentions a possible fix for Win8.x (KB2878604).

And lastly, I'm really glad that XP introduced this separation. Win2k made the network drives connected as admin visible to the user, but they were not accessible - really annoying. Don't know if this is an issue when this policy is enabled on Win7 or higher.

Regards
Dalai

[ghisler(Author)]

No, you misunderstood. It does work correctly as long as you make your drives point to shares, e.g. z:\ -> \\server\share, and NOT to subdirectories of shares.

[easydoor]

Hi,

I am on the latest version of Total Commander and Windows 11.
I applied the above-mentioned information, but I still facing the same issue.
It is very frustrating when I copy something from the mapped drive in Explorer and paste it into Total Commander.
Is there any permanent fix for this?
Image: https://ibb.co/WW0rqCV

[ghisler(Author)]

As I have explained before, running a program as administrator is treated like a separate user by Windows, and that user has its own network drives. If you cannot get EnableLinkedConnections to work, you need to run Total Commander as admin and then create network connections for it.

[easydoor]

Thank you very much for your effort.
I activated the registry entry, but just with that option didn't work.
Running TT as an admin fixed the issue.

[ghisler(Author)]

Once you have created the connection as admin, you should be able to use that connection also as a normal user with the button "As administrator" when copying.