3ds max not "realizing" network drives are available

[Art48]

Ever since I enabled UAC (policies...., annoying sh**) max won't recognize the two networkdrives I mapped in windows anymore.
I mean they are available, I can navigate to them in the windows explorer, and in the windows explorer itself there are no red X's.
When I open max then select the "open" command (Ctrl+O) and the window to select files pops up, the network drives have red X's, BUT I can access them fine if I click on them.

The only solution I have come to this far is starting max, then from inside max open any max file on that network drive, after it has opened, max recognizes that networkdrive perfectly and everything works for the rest of the windows session.

Is that a known strange behaviour, anyone else have a better solution for this?

[AlexP]

Try navigating via the network - computer name instead of drive letter.
We've actually got rid of all the drive letter mapping and only go via UAC path in explorer and max etc.

[Art48]

The last I wanto to do is to change this all to UNC tbh. All the scripts -.-.
Anyways I got it to work since I switched OFF "Run as Administrator". Since I switched it off, it works fine...strange. I switched it on at some point due to some other issues I think but we'll have to see.

[Vizioen]

Was going to suggest this. I have this in most of my programs that ran as administrator. It's a windows thing.

[Art48]

And there I was thinking running stuff as administrator actually would cause LESS problems...

[benb32]

Sorry if this gets a bit techie... but it will allow you to keep your network drive paths, without renaming to UNC.

For security reasons, network drive mappings in Windows are user-specific. Administrative group membership has nothing to do with it. Each user sees the "global" drive definitions which correspond to local devices (A:, C:, D:, ... whatever), plus those network drive definitions which they themselves created. Windows User Account Control UNC, can also cause problems with accessing mapped network locations - but please don't read "disable uac" as it's not a bad idea to keep it switched on.

On a code level, the identity of the user account which calls the drive-mapping DefineDosDevice API determines who gets to "see" the mapping. If the account is anybody other than SYSTEM, the mapping will be placed into a session-specific namespace which is invisible to other sessions/accounts.

In situations where you want all users to see a particular network drive, the workaround is to map the network drive in the SYSTEM context. That will lead to the definition being placed in the global namespace where it will be available to all users, just like A:, C:, ...

One way to run code as system is to use the PsExec utility from sysinternals with its "-s" command line option (can also use power shell). Start a CMD prompt in an elevated context (run as admin), and use that to issue something like the following command:

PSEXEC -S -I CMD.EXE

That will start a second CMD instance which will run in the SYSTEM context. If you map the Z: drive from there, it'll subsequently be visible to all users:

NET USE Z: \\TargetName\TargetShare

You could also specify the "net use" comand-line argument to PsExec, but it's not as obvious what's happening, expecially while you're tinkering with this stuff the first few times.

[Art48]

Thank you very much for that thorough explanation, much appreciated.
For the moment everything works fine, but on the mid-term I wanted to set up backburner and DR as services so I can access them without having to actually log on, and as soon as I will start this "operation" I think your information will come in handy. I will set this up when we have less work, at the moment it just seems a little dangerous to tinker with that stuff, especially since I am no IT expert.

[benb32]

You're welcome - I agree with tinkering, would run some tests on an independent machine to get everything as you want first. It's not too dangerous overall, either the mappings will work or they won't. Probably better to workout which plugins are making you need to run Max as admin in the first place. Normally finding their location and check their permissions will quickly solve your issues - as well as allowing they to write any config back to the registry / .ini files. All the best Ben

[Art48]

Probably better to workout which plugins are making you need to run Max as admin in the first place.

Would I need to test every single one? Why would one want to run as administrator?

check their permissions will quickly solve your issues - as well as allowing they to write any config back to the registry / .ini files.

How would I go about giving them permissions? I looked for it but is it really just enabling the "Run as administrator" option? What if they're DLLs or other stuff apart from .exe? How would I allow them to write somehere?

[benb32]

No, no need to test every single one. Once your script works it will be absolutely fine on all your other nodes.

My response was created in part to help with the times Max doesn't see or work with assets on mapped network drives. One reason for this is if Max is run as an administrator. Hopefully you won't need to run Max as an administrator as giving programs elevated privileges when they don't absolutely need it is not a good idea. In fact there are a whole load of other side effects that you'll experience, for example being able to cut and paste between other programs.

Anyway, before I digress, best not to run Max as an administrator (I only mention the plugins, as a few of them don't setup their permissions properly, and running Max as admin can appear like a quick fix). The point to take away is that you have to map the network drive as the user that will be running Max on your remote nodes. If you aren't running Max as Admin you can just use a Net Use script once on each node and the mapped drive letter will be persisted.

If you are running max as Admin or something is running in the context of SYSTEM user account, then you'll need to use the trick I showed below. Hope this clears things up.

[Art48]

Yes it is all clear now, thank you!

[benb32]

Ohhh in answer to your previous question: DLLs are shared libraries that are linked into what ever process (.exe) calls them. Thus the DLL will run in the user context of it's parent process.

You can find the permissions of a file by right clicking -> properties -> security tab. If you did need to make a change, you would make sure the user account, that it will run under, is listed and you have read / modify / execute enabled for that account.

Honestly, you should very rarely ever have to do this last step, it only ever needs to be checked on things that were written a long time ago - when windows was far more relaxed on security stuff for local users.