cron and network drives

Mon Aug 18 21:51:00 GMT 2003

Elfyn McBratney wrote:
>> I really wish that somebody would address this issue once and for 
>> all. I often here such things as a "public mount" but to date nobody 
>> has ventured a guess as to what a "public mount" would be and how it 
>> would differ from a "non public mount". I think I have a situation 
>> here that clearly shows that something is odd whereas on one machine 
>> a mounted drive is available via cron and on another machine it is 
>> not. Both machines are setup nearly identically with the same user 
>> (in the same domain though geographically separated by thousands of 
>> miles). The only difference I see is that the versions of Cygwin and 
>> cron are different.
>> I think Larry is actually speaking shares here, not mounts.

Sorry for the incorrect terminology. Substitute "public share" for 
"public mount".
> The reason people might not be explaining this is perhaps because it's 
> just a case of common sense. Public meaning access-to-all, share, in 
> this case, meaning a file share ...It really shouldn't need explaining.

AFAICT it is a public, access-to-all, share. Tools from hostb appears to 
be the same style of share as Tools from hosta.
>> in question is the same, userc. Now on hosta the T drive is mounted from
>> //hosta/share. On hostb the T drive is mounted from //hostb/share (The
>> share is replicated on both machines and has bascially the same stuff -
>> Tools. This is done because of the thousands of miles of seperation
>> between the two machines).
>>>> A cronjob is setup for userc on both hosta and hostb doing merely:
>>>> * * * * * net use > /tmp/netuse
>>>> On hosta it shows the T drive is OK while on hostb it shows the T drive
>> is unavailable.
>>>> hosta and hostb are both Windows 2000 servers. hosta is running Cygwin
>> 1.3.20, cron 3.0.1-7. hostb is running Cygwin 1.3.22, cron 3.0.1-10.
>> The situation is this: There are two machines: hosta and hostb. The user
>> Double check the following
>> 1) Your /etc/passwd and /etc/group are fully up-to-date (for domain & 
> local access)

They are up to date, WRT to userc.
> 2) The cron service is running as the same user

Cron is installed identically - running as SYSTEM.
> It might also be a good idea to cut Cygwin out of the equastion, and 
> make sure you're able to do all of this from within Windows (trying 
> your `net use' from a remote-telnet session would be a good place to 
> start).

I assure you the share is indeed in use everyday by everyone at the site.
My understanding of accessing mount points (shares that have been 
mounted to a drive letter) is that if you telnet or login (or 
switchuser) in such a way as to have a passwordless login then mount 
points are marked as unavailable. Further I understand that cron runs as 
SYSTEM and switches user to the owner of the crontab. Thus a 
passwordless login has occurred therefore mount points are unavailable. 
Yet on hosta it works but on hostb it fails.
> There's also a trick you can do with `at' that might help. Type:
>> at /interactive HH:MM cmd
>> at the (Windows) command line. At (no pun intended) HH:MM a 
> LocalSystem owned
> command prompt should pop-up, where you can try out `net use'. If it 
> doesn't
> work (`net use'), it's a problem with your Windows configuration.

But I thought, and perhaps I'm wrong, that is it not SYSTEM that I need 
worry about rather whether or not userc has access to the mounted drive 
(OK) or not (Unavaliable).
I've tried the at command to no avail. No window is popped up. Yes I 
included /interactive. Problem is perhaps that hostb, the machine where 
the problem is, is in China and I'm accessing it via Remote Desktop. A 
cmd process runs, as SYSTEM, but there is no window. Apparently 
/interactive and Remote Desktop do not like each other! :-(
>> that explaination is "because the share on hosta is public and on hostb
>> it is not" then please let me know what a "public mount" is and how can
>> I make the mount on hostb public.
>> Can somebody explain why this works on hosta and not on hostb? And if
>> I wouldn't even want to venture a guess. If you haven't already supplied
> cygcheck output from both machines, that would make a good data point.

Attached.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hosta.cygcheck.out
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030818/690576b9/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hostb.cygcheck.out
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030818/690576b9/attachment-0001.ksh>
-------------- next part --------------
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/