This is the mail archive of the
mailing list for the Cygwin project.
Re: permission denied for NTFS network shares
- From: Genady Veytsman <genadyv at mysticom dot com>
- To: cygwin at cygwin dot com
- Cc: Pierre dot Humblet at ieee dot org, Genady Veytsman <genadyv at mysticom dot com>,chris at atomice dot net
- Date: Mon, 23 Dec 2002 18:08:55 +0200
- Subject: Re: permission denied for NTFS network shares
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):
#! /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
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
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 Veytsman wrote
If you are the only user needing to rsh into the system
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.
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
I have not tried any of that, let us know if it works.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html