mkstemp <filename> failed

jw schultz jw at
Mon May 5 12:46:05 EST 2003

On Fri, May 02, 2003 at 09:48:42PM -0400, Keith Mastin wrote:
> I'm not really what you would call a linux newbie, but I managed to run
> into a problem with rsync that has me stumped.

I was going to let someone else respond but none have.

> I want to conduct un-attended backups of various files and directories
> over about 3000 miles of Internet, so I chose sshd and rsync for the job.
> I wrote a pair of scripts to do the job, the first to run incremental tars
> on the localhost, the second to run the rsync client.

What do you mean by incremental tars?  Using rsync, whole
tars would make more sense.  Then again, unless you are
doing cross-platform why bother tarring at all.

> The first script is owned by root and the other owned by me ($USER). The
> root file tars a bunch of directories and changes their ownerships and
> permissions to $USER:$USER 644, then invokes the second script. The
> second script makes the ssh connection and does an rsync backup to the
> fileserver. Everything seems to be in order, but it doesn't work.
> Here's the command that runs rsync on the client:
> /usr/bin/rsync --verbose  --progress --stats --compress --rsh=/usr/bin/ssh \
>       --recursive --times --perms --links --delete --include "*" \
>       /web/tars/* kmastin at

You seem to have gone hog-wild with discrete options so i'll
start there.  --include "*" is the default unless you have
excluded something.  Are there any hardlinks to preserve?
is /web/tars/* going to match any directories to warrant the
--recursive option?  Please turn off progress if you are
going to post log output.  -vv would be better for debugging.

> Here's a sample of the output:
> kmastin.tar
>    635361280 100%    3.76MB/s    0:00:00
> layer1.tar
>     24145920 100%    3.95MB/s    0:00:00
> logs.tar
>    229990400 100%    1.59MB/s    0:00:00
> mkstemp .kmastin.tar.yK1Qmu failed: Permission denied
> mcleodlake.tar
>     85278720 100%    3.91MB/s    0:00:00

The permission denied can be a result of not having
permission to create the file or lacking permission to chmod
the file.  It doesn't look like it from the logs but are
there any subdirs that you did a chmod 644 to?

> The files on the server are unchanged, and a few files that I added as
> controls did not transfer (timestamps and sizes are unchanged), although
> they all took up bandwidth for transfers/updates.
> I looked in the logs and did a google for this, but found nothing
> relevant. There was one reference to the fact that rsyncd.conf spec's
> rsync to run as uid/gid nobody:nobody, so I tried changing them to
> kmastin:kmastin. No joy, same errors.
> The second suggestion on the same thread was to make read only = false in
> the rsyncd.conf file, which I did but also get the same errors.

You aren't connecting to rsyncd so the rsyncd.conf is
irrelevant and there will be log rsyncd.log entries.


> As you can see from the above outpuyt, I can connect and it looks like
> things are working for the first minute or so, and then the errors start.
> The filenames are about 15 characters each max (ie. /web/tars/home.tar ->
> /chroot/mcleod/home.tar), so I think long filenames are not the issue
> here.
> The system is redhat-7.3, all up2date'd. I got so PO'd that I did rpm -e
> rsync and installed from sources, thinking the latest version (2.5.6-2)
> might be a fix, but again no joy.

Is that both ends or just the client?

What pray tell is 2.5.6-2?  There is no such official version.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list