zero length file transfer

Jim Parsons parsons at clearway.com
Thu Dec 9 19:30:25 GMT 1999


Hello,
  
Problem:  I need to backup our local development CVS tree from a Linux
box where it resides to an NT box running NT Server on our local net.

Approach:  I have a script in place that tars up the dir tree on the
Linux box, then gzips it, and then calls
smbclient //NTbox/backupdir -U NTaccountname%NTpasswd -c 'put
backup.tar.gz'

This script runs from a cron as root.

Drastic Results!: I know this may sound unusual, but the folks on this
list are my first choice for asking why this strange thing is
happening--when I set the cron to start running a couple of nights ago
at 2:00AM, I found that I was getting a zero length file on the target
dir on the NT box; despite the fact that the entire script/cron had
tested fine earlier in the day when I was at work.

Further testing has proved the following:
If I set the cron to go off every hour on the hour, the backup works
perfectly, and the file backup.tar.gz transfers perfectly. The FIRST
smbclient 'put' after midnight fails though! After that backup attempt,
every thing once again is normal, and the backup proceeds properly at
1:00AM, 2:00AM, 3:00AM.....

1) The cron runs as root on the CVS repository linux box, with no one
logged in.

2) From another linux box, I have a script that calls
smbclient //NTbox/backupdir -U NTaccountname%NTpasswd -c 'dir * '
every 15 minutes and writes the results into a logfile...most of the
time the entire tar, zip, and smbclient transfer take about 5 minutes
according to the timestamp on the file residing in the target directory
returned from the 'dir *' command. The one that fails at midnight takes
18 minutes because the time stamp on the zero length file in the target
dir reflects this.

3) The times on all of the machines are correct; within one or two
minutes of each other...all the right time zone.

4) If I do not make a backup and put it on the NT box from before
midnight until 2:00AM, or 3:00AM, or 4:30AM...or whatever time after
midnight I choose, it fails, but then the next attempt succeeds, as do
all future attempts until the magic midnight hour!

5) The file on the Linux box that gets tarred and zipped is proper
size...the file is not zero length on the Linux side of the connection
before the 'put...' is executed.

6) The NT acct for the backup (referred to as NTaccountname in the
smbclient command above) has permissions set around the clock on it...no
restrictions

So The NT guy here thinks its my problem, and I think it is his
problem...

Can anyone shed any light on this? Is this a samba issue?

Major apologies if this list isn't pertinent...I chose what I thought
was the closest domain!

Please cc any responses to me as I am not subscribed yet...

Jim Parsons


More information about the samba-ntdom mailing list