murphy wrote:
> [posted to rush.general]
>
> we did last test and rerun the rushd under normal system account.
> previously it was run under Administrator account and it works now!
If it's running as the system account, that means rushd will
run as whomever your window manager is logged in as.
If that user is "soft", that's probably why it works (see my last message).
If that's the case, try configuring the rushd service to run as 'soft',
so that the daemon remains running as that user, regardless of who's
logged into the machine.
I do not recommend you run rushd as the 'normal system account',
because then rushd will not operate unless someone is logged in,
and it will stop short if someone logs out/in as someone else.
I'd suggest seeing my last message for a few tests.
My guess is this is not environment oriented, but rather user
permission oriented. Probably the local Administrator does not
have access to the //skserver/oscar volume because the local
administrator's password doesn't match the one on skserver,
causing file access not to be available.
Possible Solutions:
If you want rushd to run as "administrator", then make sure
the password on "snap" is the same as the local admin's password
on "skserver", so that the permissions match up.
*Or*, if matching the administrator's passwords are not possible,
then consider configuring Rushd to run as the user 'soft' instead,
since that user probably has matching passwords with skserver,
and might be why it works from your DOS window tests as 'soft',
(and when you have rushd set up to run as the 'system' account)
--
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|