cron作业中的cifs写入错误

Question

编辑:解决方案

在Tim的帮助下，我确定更多的数据写入是失败的，而不是较小的。当我以交互方式运行脚本时，为什么它们没有失败，这里我不know...But是修复(wsize=4096的新挂载选项)：

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

wsize=4096是一个相当小的写(默认是14倍)，所以我可能会尝试找到限制。但现在我很高兴它起作用了。

原始问题

我有一个shell脚本来备份我们的svn存储库。我用焦油把他们送到NAS ( Drobo)来支持他们。脚本负责安装和卸载网络共享本身。

当我直接运行脚本时，脚本本身运行良好，但是当通过cron运行时，它似乎失败了，syslog中出现了一些与CIFS相关的错误。首先，下面是脚本：

#!/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 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

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

        exit 1
    fi

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

下面是日志条目(一个注意事项:它似乎成功地创建了“svn-备份-tem.tar”文件，在此之后错误开始发生)：

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

在脚本完成之前，最后一个错误行可能会出现多次。有洞察力吗？谢谢!

Answer 1

您是否已验证是否正在创建具有所有正确内容的备份？

有几个原因可以让你看到这些错误。

1. 您可能会在创建时(在tar和mv命令期间)看到与文件属性设置有关的纯信息性错误。CIFS挂载下的NTFS或FAT文件系统可能实际上不支持某些系统调用，这可能不是实际的错误。
2. 您是否尝试过在本地创建tar存档，然后将其复制到NAS？

此外，您还可以通过(从fs.cifs自述)启用更详细的日志记录：

echo 7> /proc/fs/cifs/cifsFYI cifsFYI函数作为位掩码。将其设置为1可以对各种信息性消息进行额外的内核日志记录。2启用非零SMB返回代码的日志记录，4启用记录花费超过1秒的请求(字节范围锁定请求除外)。将其设置为4需要在源代码中手动定义CONFIG_CIFS_STATS2 (通常通过在cifsglob.h开头设置它)，并将其设置为7启用所有三个。最后，可以通过以下方法启用跟踪smb请求和响应的启动: echo 1> /proc/fs/cifs/traceSMB

这两个选项可能为您提供足够的信息，以了解您接下来的步骤应该是什么。

Answer 2

这闻起来像是权限问题。手动运行脚本时，用户的用户ID是多少？它与运行cron作业的UID相同吗？

请注意，如果您以root身份运行cron作业，您可能没有访问挂载文件系统上的内容所需的权限。在工作场景中，尝试将脚本添加到用户的cron选项卡：crontab -e应该是您的朋友。