On Sat 23 Apr 2005, Serge van Ginderachter wrote: > In the mean time I have been experimenting with the newest version. > Troubleshooting was a little hard, as I equally was struggling with an > NFS problem at my provider. It is that NFS space I am rsync'ing with. > > As of today, I have no more time-out problems. I am now using the latest > 2.6.4-1 version.
Ah, good news. > Where at first I was succesfully syncing using the --timeout option, > this is not necessary any more. > > Right now I'm not sure if this was in my case a pure rsync problem, or > related to the NFS problem. My suspicions would be NFS (but then I'm not objective :-) > On a side note, I noticed that using the --timeout option for remote > backups using ssh transport, failed when the remote user has > /usr/bin/scponly (v4.0-1) as his shell. The error rsync returns is: > > >/usr/bin/rsync -av --delete --numeric-ids --timeout 300 --rsh=/usr/bin/ssh > >\ > > [EMAIL PROTECTED]:/mnt/backup/ \ > > /BACKUP/snapshots/daily.0/server/ > >invalid characters in scp command! > >here:=300 --numeric-ids . /mnt/backup/ > >try using a wildcard to match this file/directory > > The problem goes away when using /bin/sh as the remote user's shell. > I'm not sure if this is a bug or a feature, and if I should file a > separate bug report in this? Do you mean that without the timeout option, it does work with this scponly shell? I would expect that "scponly" would imply not being able to run any given command: only scp would be permitted. I'll look into scponly later (I had never heard of it up to now). Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
