permission denied for NTFS network shares

[Genady Veytsman]

I didn't manage to make "cygrunsrv -u ..." to work.
The service is installed but refuses to start.
Besides its quite a nuisance to add all those fancy priviledges to every 
user/computer that will use rsh.

The situation is like that:
I have interactive RSH that works fine and noninteractive rsh (using 
.rhosts) that denies access to network shares.
So I used "Expect" to pass a password and command to rsh (as Chris 
January have suggested), converting interactive RSH to noninteractive 
and keeping all the benefits.
Here is the "Expect" script that does a job (its actually modifed expect 
example from the WEB):

exprsh.expect:
================================================
#! /bin/expect -f
# wrapper for RSH to make it non-interactive
# server name is passed as 1st arg, command as 2nd

set password DefaultPassword
set user     DefaultUser
set server [lindex $argv 0]
set cmd [lindex $argv 1]
spawn rsh $server -l $user
expect "Password:"
send "$password\r"
expect '$'
send "$cmd\r"
expect eof
================================================

The drawback of this solution is that you must have a default domain 
user whose password is known to everybody (like the password of farm or 
lab computer).
The good part is that you don't need to play with permission on any 
computer. This wrapper will work plug and play on any computer where
"inetd" service is installed.

Best regards and thanks to everybody who tried to help
   Genady

> Genady Veytsman wrote
> 
>> Are you saying that there is no way whatsoever to have RSH without
>> passwords? I need it for running scripts/programs on different NT
>> machines. Interactive behaviour (login/password) will not allow that
>> since you can't hardcode your passwords in scripts.
> 
> If you are the only user needing to rsh into the system
> you could try to run the daemons under your own name
> (cygrunsrv -u, read the README). You may also have to change
> ownership of key files and such.
> A more ambitious/risky project is to give privileges to create tokens
> etc.. (see README) to a domain account and run the daemons under
> that account.
> I have not tried any of that, let us know if it works.
> 
> Pierre 





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/