cifs 在 cron 作业中写入错误

cifs 在 cron 作业中写入错误

编辑:解决方案

在 Tim 的帮助下,我确定写入较大的数据会失败,而写入较小的数据则会失败。我不知道为什么当我以交互方式运行脚本时它们没有失败...但这里有解决办法(新的挂载选项 wsize=4096):

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

wsize=4096是一个相当小的写入(默认是 14 倍),所以我可能会尝试找到极限。但现在我很高兴它有效。

原问题

我有一个 shell 脚本来备份我们的 svn 存储库。我通过将它们转移到 NAS(Drobo)来备份它们。该脚本负责安装和卸载网络共享本身。

当我直接运行脚本时,脚本本身工作正常,但是当通过 cron 运行时,它似乎会失败,并在系统日志中出现一些与 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-backup-temp.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

然后,在脚本完成之前,最后一个错误行会出现多次。有什么见解吗?谢谢!

答案1

您是否已验证所创建的备份内容是否正确?

您看到这些错误的原因可能有多种。

  1. tar您可能会在创建时(在和命令期间)看到与文件属性设置相关的纯粹信息性错误mv。 CIFS 挂载底层的 NTFS 或 FAT 文件系统实际上可能不支持某些系统调用,并且这可能不是实际错误。

  2. 您是否尝试过tar在本地创建存档,然后将其复制到 NAS?

另外,您可以通过(来自 fs.cifs README)启用一些更详细的日志记录:

回声 7 > /proc/fs/cifs/cifsFYI

cifsFYI 用作位掩码。将其设置为 1 可以启用各种信息消息的附加内核日志记录。 2 启用记录非零 SMB 返回代码,而 4 启用记录需要超过一秒才能完成的请求(字节范围锁定请求除外)。将其设置为 4 需要在源代码中手动定义 CONFIG_CIFS_STATS2(通常通过在 cifsglob.h 的开头设置),并将其设置为 7 会启用所有三个。最后,可以通过以下方式启用跟踪 smb 请求和响应的开始:

回声 1 > /proc/fs/cifs/traceSMB

这两个选项可以为您提供足够的信息来了解下一步应该做什么。

答案2

这听起来像是权限问题。手动运行脚本时用户的用户ID是什么?它与运行 cron 作业的 UID 相同吗?

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

相关内容