Does a drive mapping stay mapped if a different user logs onto a PC - mapped-drive

So I want to be able to map a drive but when I log out of the PC and someone else logs, I want that drive to still stay mapped.
Is this possible?

You could solve this with login scripts

Related

Windows file system filter driver on mapped network drive

Is it possible to attach an FS filter driver on a mapped network drive?
I'm really new to this filter driver work and currently testing a demo version of an SDK. It works fine on my local drive and I was able monitor and even deny file creation. But it doesn't seem to work on a mapped network drive.
So my question is: Is it even possible to do that?
Of course.
You simply need to check in you instance attach if your filesystem type is a network filesystem.
Read more here, especially the VolumeDeviceType and VolumeFilesystemType parameters.
Good luck,
Gabriel

Windows file share - How to check log who has accessed what in my system

By mistake i shared my "User" group of system and which allowed everyone to access my folder under - users/XXXX/desktop...
Is there any way to check the logs to identify who has access my desktop items or tried to download my confidential information from Desktop ?
Your help is deeply appreciated.
I guess net view can help you (see http://ss64.com/nt/net_share.html)

Permission is not letting Service interact with mounted virtual folder / drive

I'm mounting a folder to a virtual disk like this (I'm on Windows XP):
subst z: c:\virtual_disk
This works perfectly okay for one thing, I have a Service (created with C++ / CreateService(...) ) running and it can write files to c:\virtual_disk but not to z:\
I'm using classic fopen, fwrite etc.
I have, I think, narrowed down the problem to some sort of permission problem, I'm not sure though.
The service runs on the "localSystem" account and the folder is mounted by me using an administrator account.
Any help appreciated!
Mapping is per user. If you mapped Z using your own account, it won't catch for the local system account. You can either run the service under your own account, or have it do its own mapping.

Not able to access network drive from VB.NET Windows Service

I have a Windows service developed in VB.NET. This Windows service picks a file every night at 8 PM from copies a file from my C:\ftpDocs to Y:\FtpDocs folder.
Y: is a mapped drive which is \\sourceServer\Output files. When I run the same code from a VB.NET Windows application instead of a Windows service it is working absolutely fine. But from the service it is throwing access denied error accessing \\sourceServer\Output.
It seems the Windows service runs from C:\windows\system32. For this reason I tried changing the current directory to C:\ftpService (This is the folder where my application is).
To access the mapped drive I provide a userid and password which is not my Windows userid and password. Do you think this is the reason why it is not able to access it from the Windows service?
If yes, how is it working from Windows application? This issue is not going away for the past one month now.
What drives are currently mapped is maintained per user -- it'd be a big no-no for me to be able to access files on a share on which you have credentials just because we're both logged on at the same time.
Your service will need to map the share itself using saved credentials of some kind (you could hard code them, if you like, though that's not terribly secure and represents a maintainability burden besides). A good example of how to do this is here -- though, I haven't used this code, I've just read the article.
Typically a Windows service runs under an id whose credentials are not authorized to access files on the network. Try running your windows service under the domain account which can access the network files. Make sure that this account has access to both the network and local folders/files that it will be reading and writing.
Also, you'll want to use the UNC path, not a mapped drive. The mapped drive won't be mounted for the service.

service doesn't behave the same as command line

I am running on a Windows Server 2003. This is my problem:
I wrote a Perl script to automate the copy of some files from my Server machine to some network drives. I am using xcopy to copy the files. My problem is the permissions.
If I run the script from the command line, it works, all the copies are successful.
If I try to run the script using a service all the copies fail. This service is a program that I wrote that takes the script and runs it. In the background all it is doing is to call the C function 'system' and it runs the same program that I can run from the command line.
I have tried many variations of this to figure out what is wrong with it but I can't see why the service would not run the same way I run it from the command line.
I set up the service to run as the same user I am using from the command line.
I also tried to map the network drives as the user that has writing permission but the result is the same. Manually the script works, from the service, it doesn't.
Any suggestion is appreciated.
Thanks
Tony
The service may be running as the system and not have access to the network drives. In the Service settings, change the service to run under your account (or an account with the relevant permissions/mappings).
When the service runs, it uses whatever credentials you specify in the Services manager of Windows. The default, LOCAL SERVICE, probably does not have permission to access the resources to be copied.
Create a new user account with the minimum set of permissions needed to perform the copy and configure your service to run under that account.
I did figure out the issue (I think), and that matches what I later found in another post:
https://serverfault.com/questions/4623/windows-can-i-map-a-network-drive-for-a-service-account
<...Persistent drive mappings are only restored during an interactive login, which the service does not use. I believe the only way to get a service to use a network drive is for that service to map the drive itself or alternatively for it to us a UNC path instead of a mapped drive.>
What I did was mapping the drive using the service and that seems to work. It turns out, if I map the drive and save credentials, then I can access later the drive without having to map it again. I don't know why this approach seems to work though.
-Thanks everybody for your help.
Tony

Resources