samba 卷影副本无法匹配
测试机器正在运行 Ubuntu 服务器 20.04 LTS,我尝试将 zfs 快照作为卷影副本公开到 samba 共享,但失败了。
这是 smb.conf 共享块:
[Storage]
comment = NAS Storage
path = /storage/smb
browseable = yes
read only = no
guest ok = no
create mask = 0755
directory mask = 0755
vfs objects = shadow_copy2
shadow:format = "CST-%Y.%m.%d-%H.%M.%S"
shadow:localtime = yes
shadow:snapdir = .zfs/snapshot
;shadow:basedir = /storage/smb
这些是 zfs 快照:
root@samba-1:/var/log/samba# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
storage/[email protected] 16K - 26K -
storage/[email protected] 16K - 26K -
storage/[email protected] 56.5K - 66.5K -
我在日志中找到了这些:
[2022/03/09 12:53:40.750713, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/smbd/files.c:824(file
_name_hash)
file_name_hash: /storage/smb//storage/smb/.zfs/snapshot hash 0xb6dc192a
[2022/03/09 12:53:40.750846, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_co
py2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": .
[2022/03/09 12:53:40.750872, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring .
[2022/03/09 12:53:40.750892, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": ..
[2022/03/09 12:53:40.750910, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring ..
[2022/03/09 12:53:40.750928, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": CST-2022.03.09-00.01.17
[2022/03/09 12:53:40.750947, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring CST-2022.03.09-00.01.17
[2022/03/09 12:53:40.750973, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": CST-2022.03.08-23.39.39
[2022/03/09 12:53:40.751003, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring CST-2022.03.08-23.39.39
[2022/03/09 12:53:40.751030, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": CST-2022.03.08-23.25.35
[2022/03/09 12:53:40.751053, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring CST-2022.03.08-23.25.35
[2022/03/09 12:53:40.751112, 5, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/smbd/files.c:636(file_free)
freed files structure 0 (4 used)
[2022/03/09 12:53:40.751137, 10, pid=3211, effective(101105, 100513), real(101105, 0), class=vfs] ../../source3/modules/vfs_default.c:1482(vfswrap_fsctl)
FSCTL_GET_SHADOW_COPY_DATA: 0 volumes for path[.].
为什么比较不匹配?我使用date +%Y.%m.%d-%H.%M.%S
生成快照名称
The test machine is running Ubuntu server 20.04 LTS, I'm tring to expose zfs snapshots to samba share as shadow copies but failed.
Here is the smb.conf share block:
[Storage]
comment = NAS Storage
path = /storage/smb
browseable = yes
read only = no
guest ok = no
create mask = 0755
directory mask = 0755
vfs objects = shadow_copy2
shadow:format = "CST-%Y.%m.%d-%H.%M.%S"
shadow:localtime = yes
shadow:snapdir = .zfs/snapshot
;shadow:basedir = /storage/smb
And these are zfs snapshots:
root@samba-1:/var/log/samba# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
storage/[email protected] 16K - 26K -
storage/[email protected] 16K - 26K -
storage/[email protected] 56.5K - 66.5K -
And I found these in logs:
[2022/03/09 12:53:40.750713, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/smbd/files.c:824(file
_name_hash)
file_name_hash: /storage/smb//storage/smb/.zfs/snapshot hash 0xb6dc192a
[2022/03/09 12:53:40.750846, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_co
py2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": .
[2022/03/09 12:53:40.750872, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring .
[2022/03/09 12:53:40.750892, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": ..
[2022/03/09 12:53:40.750910, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring ..
[2022/03/09 12:53:40.750928, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": CST-2022.03.09-00.01.17
[2022/03/09 12:53:40.750947, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring CST-2022.03.09-00.01.17
[2022/03/09 12:53:40.750973, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": CST-2022.03.08-23.39.39
[2022/03/09 12:53:40.751003, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring CST-2022.03.08-23.39.39
[2022/03/09 12:53:40.751030, 10, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:1870(shadow_copy2_snapshot_to_gmt)
shadow_copy2_snapshot_to_gmt: no match "CST-%Y.%m.%d-%H.%M.%S": CST-2022.03.08-23.25.35
[2022/03/09 12:53:40.751053, 6, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/modules/vfs_shadow_copy2.c:2064(shadow_copy2_get_shadow_copy_data)
shadow_copy2_get_shadow_copy_data: ignoring CST-2022.03.08-23.25.35
[2022/03/09 12:53:40.751112, 5, pid=3211, effective(101105, 100513), real(101105, 0)] ../../source3/smbd/files.c:636(file_free)
freed files structure 0 (4 used)
[2022/03/09 12:53:40.751137, 10, pid=3211, effective(101105, 100513), real(101105, 0), class=vfs] ../../source3/modules/vfs_default.c:1482(vfswrap_fsctl)
FSCTL_GET_SHADOW_COPY_DATA: 0 volumes for path[.].
why the compare is no match? I generate the snapshot name using date +%Y.%m.%d-%H.%M.%S
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我的系统是 Raspberry Pi 4,带有 Raspberry Pi OS lite 64 位和 Samba 版本 4.13.13-Debian,我遇到了同样的问题,但找到了一个奇怪的解决方案:
你必须设置
以下电子邮件 Samba 邮件列表给了我一个线索。
My system is a Raspberry Pi 4 with Raspberry Pi OS lite 64bits and Samba Version 4.13.13-Debian and I'm having the same problems, but found a strange solution:
You have to set this
The following e-mail on the Samba mailing list gave me a clue.