With Tim's help I determined that larger writes of data were failing versus smaller ones. Why they didn't fail when I ran the script interactively, I don't know...But here was the fix (new mount option of wsize=4096):

if mount -t cifs -o guest,wsize=4096 //drobonas/public /mnt/drobonas-public; then

wsize=4096 is a pretty small write (the default is 14x that), so I might experiment to find the limit. But for now I'm just happy it works.


I've got a shell script that backs up our svn repositories. I back them up by tar'ing them over to a NAS (a Drobo). The script takes care of mounting and unmounting the network share itself.

The script itself works fine when I run it directly, but when run via cron it appears to fail with a few CIFS-related errors appearing in the syslog. First, here's the script:

# This script tars up a backup of the needed svn repo directories.
# It expects to be run as root so that it can mount the drobo's drive.
# There are probably ways to allow user mounting (via additions to /etc/fstab) but I'm trying to minimize setup steps.
# I personally placed it in a directory for root (/root/bin or /home/root/bin depending on your distro), then used crontab -e (again as root) to schedule it.
# My crontab looked like this (runs at 1:01 AM, on Mon-Fri, as root user):
# 01 01 * * 1-5 /root/bin/svn-backup.sh

# mount our backup drive
if mount -t cifs -o guest //drobonas/public /mnt/drobonas-public; then

    # perform the actual backup - went with tar so we can preserve permissions, etc
    if tar cvpf /mnt/drobonas-public/SvnBackup/svn-backup-temp.tar /home/svnserver/svnconf/ /home/svnserver/svncreaterepo.sh /home/svnserver/svnrepositories/; then

        # if everything worked out, we can do some cleanup

        # remove our oldest backup in the rotation
        rm /mnt/drobonas-public/SvnBackup/svn-backup-3.tar

        # rename the existing backups to reflect the new order
        #mv /mnt/drobonas-public/SvnBackup/svn-backup-4.tar /mnt/drobonas-public/SvnBackup/svn-backup-5.tar
        #mv /mnt/drobonas-public/SvnBackup/svn-backup-3.tar /mnt/drobonas-public/SvnBackup/svn-backup-4.tar
        mv /mnt/drobonas-public/SvnBackup/svn-backup-2.tar /mnt/drobonas-public/SvnBackup/svn-backup-3.tar
        mv /mnt/drobonas-public/SvnBackup/svn-backup-latest.tar /mnt/drobonas-public/SvnBackup/svn-backup-2.tar
        mv /mnt/drobonas-public/SvnBackup/svn-backup-temp.tar /mnt/drobonas-public/SvnBackup/svn-backup-latest.tar

        # do svnadmin dumps as well - helps future-proof things
        /bin/bash /root/bin/svn-dump.sh

        # we're done, so unmount our drive
        umount /mnt/drobonas-public

        # something went wrong, unmount the drive and then exit signalling failure
        umount /mnt/drobonas-public

        exit 1

    # mount wasn't successful, exit signalling failure
    exit 1

Now here are the log entries (one note: it appears to create the "svn-backup-temp.tar" file successfully, the errors start to happen after that):

Jan  5 07:52:01 giantpenguin CRON[2759]: (root) CMD (/root/bin/svn-backup.sh)
Jan  5 07:52:02 giantpenguin kernel: [21139655.823930]  CIFS VFS: Error -4 sending data on socket to server
Jan  5 07:52:02 giantpenguin kernel: [21139655.823961]  CIFS VFS: Write2 ret -4, wrote 0
Jan  5 07:52:02 giantpenguin kernel: [21139655.824007]  CIFS VFS: Write2 ret -112, wrote 0

The last error line then appears multiple times before the script presumably finishes out. Any insight? Thanks!

  • Is everything copied properly, or do some things not make it over? – gabe. Jan 9 '12 at 15:23
  • When I run it interactively everything copies over without issue. I can navigate the tar file, view the dumps from svn-dump.sh, etc. When it runs from cron it mounts the drive, creates the tar file but fails when it tries to write data. So in that scenario the NAS ends up with a file called svn-backup-temp.tar with 0 bytes in it. – super_seabass Jan 10 '12 at 14:08

Have you verified that the backups are being created with all the correct contents?

There are several reasons you could be seeing the errors.

  1. You maybe seeing purely informational errors related to file attribute setting at creation time (during the tar and mv commands). the NTFS or FAT filesystem underlying the CIFS mount may not actually support some of the system calls, and that may not be actual errors.

  2. Have you tried creating the tar archive locally, and then just copying it to the NAS?

Also, you can enable some more verbose logging via (from the fs.cifs README):

echo 7 > /proc/fs/cifs/cifsFYI

cifsFYI functions as a bit mask. Setting it to 1 enables additional kernel logging of various informational messages. 2 enables logging of non-zero SMB return codes while 4 enables logging of requests that take longer than one second to complete (except for byte range lock requests). Setting it to 4 requires defining CONFIG_CIFS_STATS2 manually in the source code (typically by setting it in the beginning of cifsglob.h), and setting it to seven enables all three. Finally, tracing the start of smb requests and responses can be enabled via:

echo 1 > /proc/fs/cifs/traceSMB

Those two options may provide you with enough information to know what your next steps should be.

  • Thanks Tim. I enabled some of that tracing and found this where the trouble starts: /build/buildd/linux-2.6.27/fs/cifs/transport.c: partial send (41484 remaining), terminating session. It seems that it doesn't get a response to its first full write of data (via a SMB message) and then gives up, as the remainder of the log looks like it's terminating everything and unmounting the drive (as I have my script set up to do). Again, this stuff works when I run the script directly so it seems strange that it doesn't when run from cron. I'll try creating a smaller tar locally and copying too. – super_seabass Jan 10 '12 at 14:03
  • There may be something in your environment that is being set by a .bash_profile or something that is not sourced by the non-interactive shell that cron opens up. You may need to explicitly set some environmental variables in your cron script for the activity with the CIFS mount to work properly. And... depending on your OS/Distro, you may be using bash as your interactive shell, but your script is using /bin/sh, and /bin/sh may not be fully compatible, as on Solaris, or Ubuntu. – Tim Kennedy Jan 11 '12 at 1:56
  • Maybe this article about simulating the cron environment will help you with some debugging. matthew.mceachen.us/blog/… – Tim Kennedy Jan 11 '12 at 2:03
  • That's a nice article, thanks. I tried following it and the script ran okay though. Now I'm trying to force usage of bash and a specific PATH in cron to see if it helps. After that it's trying the tar-and-copy you suggested. I'm also trying to make sure the two server clocks are synced to within a few seconds of each other. – super_seabass Jan 11 '12 at 14:06
  • Any luck with the local tar and copy? – Tim Kennedy Jan 13 '12 at 5:48

This smells like a permissions problem. What is the user ID of the user when running the script manually? Is it the same as the UID running the cron job?

Note that if you run the cron job as root, you may not have the required permissions to access stuff on a mounted file system. Try to add the script to the cron tab of the user in the working scenario: crontab -e should be your friend.

  • I run the script as root, and I'm using root's crontab (crontab -e as the root user). Basic session is this: (1) login as sudo-privileged user, (2) elevate to root with sudo -i, (3) run script, crontab -e, etc. Maybe I'm missing something though? Does mount -t cifs behave the same in a non-interactive environment, or do root crons not have the permissions I assume that they do (i.e., everything)? – super_seabass Jan 10 '12 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.