@ERROR access denied

[Hugh E Cruickshank]

Hi Hardy:

Thanks for your comments. They are greatly appreciated.

I tried your suggestion regarding the UID and GID. I set them to 
the owner and group of the /bak directory. Also I currently have 
the permissions on the directory at 777. I killed and restarted 
the server process and retried the command:

  rsync -avz fapmenu fisdev::bak

The results were the same.

As for the 2 configuration files, I supplied them because I had 
been testing with either box as the server, just trying to find
something that would work. The 2 were setup slightly differently.
The RH/pgiprd server was configured with the "secrets file" and
"strict modes = no" where as the SCO/fisdev box was not.

Again thanks for you comments.

Regards, Hugh

-- 
Hugh E Cruickshank, Forward Software, www.forward-software.com

From: Hardy Merrill Sent: Monday, July 07, 2003 06:57
> 
> Hugh, I'm fairly new to rsync myself, so hopefully other
> rsync gurus can either confirm or correct my thoughts here.
> My comments are below.
> 
> Hugh E Cruickshank [hugh at forsoft.com] wrote:
> > Hi All:
> > 
> > I am new to rsync so be gentle with me. I have been able to get
> 
> Me too :)
> 
> > rsync working enough to be able to list modules but not transfer
> > files. 
> > 
> > When I try to transfer a file from the client to the server I use
> > the command:
> > 
> >   rsync -avz fapmenu fisdev::bak
> > 
> > The client displays the following messages:
> > 
> >   @ERROR: access denied to bak from pgiprd.forsoft.com
> >           (192.168.2.19)    
> >   rsync: connection unexpectedly closed (80 bytes read so far)  
>          
> >   rsync error: error in rsync protocol data stream (code 12) at
> >           io.c(150)
> > 
> > While the server issues the following log message:
> > 
> >   2003/07/04 12:01:53 [15981] rsync denied on module bak from
> >                               pgiprd.forsoft.com (192.168.2.19)
> > 
> > In the above example "fisdev" is an SCO OSR5.0.4 system with rsync
> > V2.5.5 that I have downloaded as source and compiled. The daemon
> > was started from a root command line session. "pgiprd" is a RH8
> > system with rsync V2.5.5 as supplied by Red Hat. The daemon has
> > been started via xinetd.
> > 
> > It does not seem to matter which way I attempt to transfer the
> > file I end up with very similar results. Nor does it seem to 
> > matter if I attempt with either root or a "normal" user.
> > 
> > The rsyncd.conf file for fisdev contains:
> > 
> > #
> > # Global parameters:
> > #
> > #motd file	= /var/rsync/rsyncd.motd
> > log file	= /var/rsync/rsyncd.log
> > pid file	= /var/rsync/rsyncd.pid
> > #syslog facility= daemon
> > #socket options	=
> > 
> > #
> > # Default values for module parameters:
> > #
> > #use chroot	= no
> > #max connections	= 0
> > #lock file	= /var/rsync/rsyncd.lock
> > #read only	= no
> > #list		= yes
> > #uid		= -2
> > #gid		= -2
> > hosts allow	= fisdev pgiprd
> > auth users	= root hugh
> > 
> > #
> > # Module "BAK":
> > #
> > [bak]
> > comment		= Default remote backup repository
> > path		= /bak
> > 
> 
> Here's my first thought - the rsync-2.5.5 'man rsyncd.conf'
> states:
> 
>    uid    The  "uid"  option  specifies the user name or
>           user id that file transfers to and from that module
>           should take place as when  the daemon  was  run  as
>           root. In combination with the "gid" option this
>           determines what file permissions are available. The
>           default is uid -2, which is normally the user "nobody".
> 
> Notice that the default is "nobody" - since you have commented
> out the 'uid' line, the default of "nobody" takes over, and
> so if /bak directory does not give write permissions to user
> 'nobody', then you will get permissions errors like you are
> now seeing.
> 
> My suggestion is to try specifying the 'uid' and 'gid'
> parameters with a user/group that does have access to /bak -
> if 'root' owns /bak, then start by setting 'uid' and 'gid' to
> 'root'.  Although it's ok to have the 'uid' and 'gid' parameters
> as 'global' parameters, to be more precise, put the 'uid' and
> 'gid' parameters *inside* the [bak] module - that way there
> is no mistaking what the user and group must be for that
> particular module.
> 
> > The rsyncd.conf file for pgiprd contains:
> 
> I think(?) the rsyncd.conf definition on the rsync *server*
> is the only one that matters.  Since this one is for the
> *client*, I don't think this one matters at all.
> 
> HTH.
> 
> -- 
> Hardy Merrill
> Red Hat, Inc.
> 
> > 
> > #
> > # Global parameters:
> > #
> > #motd file	= /var/rsync/rsyncd.motd
> > log file	= /var/rsync/rsyncd.log
> > pid file	= /var/rsync/rsyncd.pid
> > #syslog facility= daemon
> > #socket options	=
> > 
> > #
> > # Default values for module paramaters:
> > #
> > #use chroot	= no
> > #max connections	= 0
> > #lock file	= /var/rsync/rsyncd.lock
> > #read only	= no
> > #list		= yes
> > #uid		= -2
> > #gid		= -2
> > auth users	= root hugh
> > secrets file	= /var/rsync/passwd
> > strict modes	= no
> > hosts allow	= fisdev pgiprd
> > 
> > #
> > # Module "BAK":
> > #
> > [bak]
> > comment		= Default remote backup repository
> > path		= /bak
> > 
> > Any thoughts, tips or suggestions greatly appreciated. By the way
> > I have reviewed the man pages and FAQ without seeing anything 
> > obvious. I have also attempted a google search without much 
> > success.
> > 
> > TIA
> > 
> > Regards, Hugh

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 03/07/04