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 [EMAIL PROTECTED] 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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html