EDIT: THE SOLUTIONWith 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.ORIGINAL QUESTIONI'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:#!/bin/sh# 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 driveif 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    else        # something went wrong, unmount the drive and then exit signalling failure        umount /mnt/drobonas-public        exit 1    fielse    # mount wasn't successful, exit signalling failure    exit 1fiNow 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 serverJan  5 07:52:02 giantpenguin kernel: [21139655.823961]  CIFS VFS: Write2 ret -4, wrote 0Jan  5 07:52:02 giantpenguin kernel: [21139655.824007]  CIFS VFS: Write2 ret -112, wrote 0The last error line then appears multiple times before the script presumably finishes out. Any insight? Thanks!
cifs write errors in cron job
cron;samba
Have you verified that the backups are being created with all the correct contents?There are several reasons you could be seeing the errors.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.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/cifsFYIcifsFYI 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/traceSMBThose two options may provide you with enough information to know what your next steps should be.