Need help: cron jobs can't access network drives.

Louis-Luc Le Guerrier leguerri@IRO.UMontreal.CA
Tue Sep 9 18:38:00 GMT 2003

On Tue, 2 Sep 2003, David Rothenberger wrote:

> Louis-Luc Le Guerrier wrote:
> > Hello,
> > I have tried Universal Name Convention path as well, and I still can't
> > access the network drives, even with UNC paths inside the script ran by
> > 'cron'. The same script invoked  manually accesses net drives of course.
> > 
> > I have looked at "" and understand partially
> > what they mean to do, but they don't explicitly explain how to perform
> > the tasks in Windows.
> That page explains that to access a network share that requires user 
> authentication, Windows needs a password, which isn't available to cron.
> For example, cron, running as the SYSTEM user, runs a job for 
> Administrator.  It switches to the Administrator user to run the job, 
> which tries to access a network share.  This share's permissions require 
> the Administrator user to authenticate by providing the correct 
> password.  But, cron has no such password, so the access fails.
> You should be able to access the network share if the share doesn't 
> require you to authenticate to access it (i.e., it allows ac
> "Everyone" per the Sharing settings).
The target (sharing) machine has Windows XP, and I have not yet found
how to change the share permission to "everyone". I remember that in
previous Windows versions, but Microsoft seems to have moved options
all around, and just this straight forward task seems complicated now.

I have been able to log in on the target machine as Administrator, with
the same password, and made the share again. On the server (source
machine) I also tried to create a SYSTEM account since none is in the
user account list, but it refuses to create it saying one already exists.
In any of these cases, nothing works, and I'm still unable to access
the network drive with 'cron'. 

On UNIX (cygwin) side, how can I tell 'cron' to execute with a different
user than "Administrator"? Maybe this will work. How do I provide the
password, then?

Our server has become a "Domain Server", so it might be the problem. I'm
not that familiar with domain accounts.
> As the page above also explains, accessing through a drive letter won't 
> work, so you'll need to use UNC paths, even if this works.
> If you only plan to run cron jobs for one user (Administrator in your 
> case), you may be able to run the cron service as that user.  You'll 
> have to provide the user's password when you setup the service, so 
> you'll avoid the problem described above.  However, I don't know whether 
> cron will run correctly as any user other than SYSTEM, and I haven't 
> tested this, so try it at your own risk.
How can I determine what user 'cron' runs under? If I schedule an 'id'
command through cron, 'id' shows user is Administrator, but does it mean
it is the user? 

Thanks again for helping.
> > I also noticed the 'id' command on the Cygwin shell gives "Administrator"
> > as user name when invoked manually. I also included 'id > tstfile' into
> > a 'cron' job to send the output of 'id' while in a cron, and it also
> > states "Administrator" is the user. I set up a password to the Windows
> > Administrator account, and it's the one I log in. cron still fails to
> > access network drives even though Administrator has a password and
> > I'm trying it with UNC paths. 
> When you log in to the machine's console, you provide a password, that 
> Windows uses (or tries) for subsequent network share authentication. 
> That's why you don't have to type the password in again when you access 
> the share from Windows or a bash shell running from the console.  But, 
> this password isn't available to a service running on the machine (which 
> is good), which is why cron can't access the network share.
> > I'm still puzzled, and stuck unable to access network drives.
> > 
> > Anyone can share a clearer procedure of what to do, or an example?
> You can change the share's permissions and use UNC paths or run cron as 
> the Administrator user.
> HTH,
> Dave

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list