Saving to network drive while running as a service?

Cheshire2 · Post by **Cheshire2** » Wed Jan 19, 2011 10:41 pm

I have yawcam running on an old laptop (Server 2003 SP2) without much storage, so I set up a network file share (mounted as Z: drive) to a system elsewhere on my network.

If I run YawCam as a program and use motion detection, it saves to Z:\{date}\{tstamp}.jpg just fine.

If I close YawCam (to save the settings) and select to install as a service, the streaming still works (http:\\mycomputer.domain:8081) but the motion detection no longer seems to be saving images to the correct spot.

I can't see the yawcam icon in the system tray when it is running as a service, so I can't check on the settings it's useing directly.

Any recommendations what might be amiss?

Thanks!

Post by **z3r0c00l12** » Thu Jan 20, 2011 2:17 am

I believe the reason it doesn't save to the Z: drive when running as a service is because the "System" account on your computer doesn't have a z: drive mapped. If you run it as your user, then it uses the mapped Z: drive.

I don't know if it's actually possible to map the shared drive as a service account, but you may want to try something just because it might work...

Make a batch file with the "net use Z: \\path\share /persistent:yes" command in it, make sure you input the right path in the command, then save it somewhere like C:\. Set Yawcam's motion detection to active and put the run .exe to point to the batch file. Close Yawcam, start the service and move around to trigger the motion, which in turn will make Yawcam run the batch file as a service and map the drive for the service account. You can then delete the batch file and restart yawcam. It should save to the Z: drive.

It's a long shot, but it just might work.

z3r0c00l12

Cheshire2 · Post by **Cheshire2** » Thu Jan 20, 2011 11:01 pm

I tried simply changing the associated account the yawcam service was running to a local admin, which did not fix the issue.

I will look at trying your possible solution when I have more time.
(I'm swamped with work, yay!)

Post by **z3r0c00l12** » Fri Jan 21, 2011 2:08 am

I didn't think about that, it could've worked, but since it didn't I'm guessing it's because your mapped drive (Z:) might not be persistent, and it wasn't mapped under the Services session. Can you make sure you have it set to persistent? Just reboot and see if it's still mapped.

Cheshire2 · Post by **Cheshire2** » Fri Jan 21, 2011 2:19 am

Yup, the Z: mount is persistent, reboot confirms it.

Thuggee · Post by **Thuggee** » Wed Feb 09, 2011 9:22 am

was there a solution for this I'm having the same issue?

TIA

Darryl

distudio · Post by **distudio** » Sat Feb 12, 2011 1:59 pm

Have you tried using a Windows UNC path to the drive as in the following example?

\\Server\Data\video

where "server" is the machine, "data" is the share and "video" is the folder.

Thuggee · Post by **Thuggee** » Wed Feb 23, 2011 11:27 am

tried it still no good

Darryl

Post by **z3r0c00l12** » Thu Feb 24, 2011 2:09 am

Thuggee, please try the first solution I provided above, it may work, I think it didn't work because the Services session is different from the console session therefore, a mapped drive in your console session might not be accessible by the Services session.

I was also thinking, you have to use an account to run your service as because you most likely don't have the permission to the shared drive using the System account.

distudio · Post by **distudio** » Thu Feb 24, 2011 8:40 am

z3r0c00l12 wrote:I was also thinking, you have to use an account to run your service as because you most likely don't have the permission to the shared drive using the System account.

And you would need to ensure that the selected account used with the service also has all the relevant permission on the share too.

I should add that using a UNC address along with an account common to both machines for the service login does allow files to be saved to a remote Windows share sans persistent mapping because this is how one of my systems is configured.