Chiphell - 分享与交流用户体验

标题: SMB是可能静默数据损坏的，同步重要文件务必开启校验(加密) [打印本页]

作者: darkclown 时间: 2022-11-27 15:33
标题: SMB是可能静默数据损坏的，同步重要文件务必开启校验(加密)
本帖最后由 darkclown 于 2025-1-9 09:32 编辑

我这段时间一直在和smb同步问题作斗争，具体可见我前两个帖子，想看结论直接看本帖。

结论：smb3.0并不能保证数据完整性，例如在我的网络环境下，win到mac传输400G的12000个文件中，会出现约8个文件损坏，每个文件中存在一段约500～1500（目前观察到的）字节的连续错误（静默无提示），文末附图。

网络环境：
路由器：国外运营商送的
服务端：win10 20H2及21H2都试过，无线网卡PCIE的AX200，开启smb共享，是ECC内存
客户端：win10笔记本(AX201)，macbook(m1)

测试组：
1. win10->win10：损坏率不稳定，损坏部分全为0，与mac不同
2. 以下几组损坏率稳定可复现，400G的12000个文件中，都会出现约5~8个文件损坏，损坏部分全为乱码：
   win10->mac(finder挂载，直接拷贝)
   win10->mac(paralles虚拟机win11中打开服务器ip，直接拷贝到mac共享文件夹)
3. win10->mac(开启smb加密)：无损坏
（以上测试中数据传输过程无任何报错，同步的文件也和原文大小等属性完全一致，只是中间有一小段与原文不同）
（所谓“乱码”是指，无规律地与原文不同，见文末附图）

讨论：
1. smb是在tcp之上的，tcp本身有16bit的checksum校验，但它的抗随机错误的能力不强，如果网络环境错误率高，可能会恰好过校验。
2. 部分坛友提到无线网的不稳定性，但是无线网本身也是通过WPA加密了数据，如果有错误校验也不会通过。
3. 如今网络环境越来越复杂（万兆、**、sdn），默认明文无校验的smb就像http一样，是不靠谱的，尤其是静默错误等你发现的时候已经晚了。
4. 必须在应用层再作校验，开启smb的加密或者签名功能，包括使用webdav等也应该开启https。

SMB3.0加密特性兼容性（欢迎补充）：
  win8和server2012以后：native支持
  mac：finder(√) parallels+win(√)
  linux：samba(√)
  iphone/ipad：FE文件管理器(√)  File Hub(√)  Infuse(√) Documents(×) nPlayer(×)
  android：MiX(×) mxplayer(×)

开启smb3.0加密的方法：
powershell执行Set-SmbServerConfiguration –EncryptData $true
详见https://learn.microsoft.com/zh-c ... server/smb-security

另外按理说开启smb签名也能起到校验的作用，但是我没做实际测试。

开启smb签名校验的方法：
powershell执行Set-SmbServerConfiguration –RequireSecuritySignature $true
详见https://learn.microsoft.com/zh-c ... -server/smb-signing

文件差异对比：
(, 下载次数: 98)

作者: wujin941005 时间: 2022-11-27 15:38
严谨的拷贝我们都用Teracopy来操作

作者: darkclown 时间: 2022-11-27 15:42
本帖最后由 darkclown 于 2022-11-27 15:56 编辑

wujin941005 发表于 2022-11-27 15:38
严谨的拷贝我们都用Teracopy来操作

嗯，最保险的是再校验一遍了，smb加密也只能保证中间的步骤不出错。只是网络传输时，额外作校验还要重传一遍，要花两倍的时间，除非服务端能直接提供hash。

作者: gartour 时间: 2022-11-27 15:46
大概率是兼容问题。

我之前用OP开SMB做远程备份盘。

经常出现几个文件在同步时总是提示文件已存在无法写入（记不太清提示原话，大概是这样）。以前同步到windows二奶机时从来没出过问题，查看NAS那边的文件，其实是同步过去了的。删除后重新同步，这几个文件还是会报错。

然后相同的硬件换成hyper-v（win+op），用winodws自带共享，同步就一点问题没有了。

作者: darkclown 时间: 2022-11-27 15:52

gartour 发表于 2022-11-27 15:46
大概率是兼容问题。

我之前用OP开SMB做远程备份盘。

你这个是不是smb实现的问题，而且有错误提示的。

静默损坏就太可怕了，我经常需要局域网同步文件，要不是偶然一次发现，长期这么下去数据千疮百孔了

作者: gartour 时间: 2022-11-27 15:56

darkclown 发表于 2022-11-27 15:52
你这个是不是smb实现的问题，而且有错误提示的。

静默损坏就太可怕了，我经常需要局域网同步文件，要不 ...

我觉得有可能是同一个原因。只是那个软件刚好有提示。

我没说清楚，不是同步几个文件不行，而是同步几千个文件，有几个文件会报错。

如果没提示，不就是无提示损坏了？

作者: hellol1 时间: 2022-11-27 15:57
有没有可能是交换机呢？

作者: darkclown 时间: 2022-11-27 15:59

gartour 发表于 2022-11-27 15:56
我觉得有可能是同一个原因。只是那个软件刚好有提示。

我没说清楚，不是同步几个文件不行，而是同步几千 ...

应该不是同一个原因，我这里遇到的smb数据损坏是上层软件发现不了的，文件大小什么的都一模一样，只是中间有一小段数据和原文不同

作者: ccchoco 时间: 2022-11-27 16:03
可能出错的环节有点多

作者: 赫敏 时间: 2022-11-27 16:05
确定是文件损坏而不是两个系统编码不一样？把mac乱码文件放到win打开呢？

作者: Phil_Libra 时间: 2022-11-27 16:07
如果没有经过交换机，高度怀疑是路由器问题导致的……smb要是出错率这高早就很多人报告这个问题了吧

作者: caileipk 时间: 2022-11-27 16:10
smb出错这么狠的话。那公司的file Server还得了。。你就没想有想到是在占用的情况下吗?

作者: uuyyhhjj 时间: 2022-11-27 16:10
哦，原来是用无线网卡当服务器的勇士，那是得开校验的，不开校验出问题很正常

作者: goat 时间: 2022-11-27 17:13
smb非加密出错可能是链路问题，同线路你可以试试ftp/nfs出不出错。

作者: 孤舟一笠 时间: 2022-11-27 19:50
之前坛内出现一例网件路由器导致的文件传输静默错误
如果设备的内存不稳定，也会导致smb文件传输静默错误
遇到这个问题，我不敢保证smb本身100%没问题，但是也要首先怀疑路由器或者内存的问题。最最不该首先质疑smb
先测试一下内存吧，看看有没有错误。LinX，P95，memtest都可以。

作者: darkclown 时间: 2022-11-27 20:42

Phil_Libra 发表于 2022-11-27 16:07
如果没有经过交换机，高度怀疑是路由器问题导致的……smb要是出错率这高早就很多人报告这个问题了吧 ...

如果是路由器的问题，那为什么tcp校验可以过呢？

作者: darkclown 时间: 2022-11-27 20:43

caileipk 发表于 2022-11-27 16:10
smb出错这么狠的话。那公司的file Server还得了。。你就没想有想到是在占用的情况下吗? ...

我觉得不一定，公司都是有线网，出错的概率小，更不容易出现并察觉这种事

作者: darkclown 时间: 2022-11-27 20:48
本帖最后由 darkclown 于 2022-11-27 21:13 编辑

孤舟一笠发表于 2022-11-27 19:50
之前坛内出现一例网件路由器导致的文件传输静默错误
如果设备的内存不稳定，也会导致smb文件传输静默错误
...

我做了很多组实验了，不开加密出错，开了就无错，实验结果是可重复的。
路由器问题为何tcp校验可以过？内存问题为何开了加密就不出错？
我现在怀疑是不是网卡封包解包TCP有问题

作者: darkclown 时间: 2022-11-27 20:52

goat 发表于 2022-11-27 17:13
smb非加密出错可能是链路问题，同线路你可以试试ftp/nfs出不出错。

每做一次实验要12小时。。暂时做不动了。我重点疑问的是，这种特点的错误是不可能过tcp校验的，那为何还会如此？

作者: goat 时间: 2022-11-27 21:35

darkclown 发表于 2022-11-27 20:52
每做一次实验要12小时。。暂时做不动了。我重点疑问的是，这种特点的错误是不可能过tcp校验的，那为何还 ...

可以稳定复现就整理下给samba提issue，然后扔给对面，除非你打算自己修。

作者: AxIaTErN 时间: 2022-11-27 21:38
我怎么记得有个帖子说的netgear的设备会造成smb数据被篡改？

作者: darkclown 时间: 2022-11-27 21:42

AxIaTErN 发表于 2022-11-27 21:38
我怎么记得有个帖子说的netgear的设备会造成smb数据被篡改？

帮忙找找那个帖子呗，我没找到

作者: darkclown 时间: 2022-11-27 21:53

goat 发表于 2022-11-27 21:35
可以稳定复现就整理下给samba提issue，然后扔给对面，除非你打算自己修。

我不是用的samba啊，提给微软/intel他们会理吗？

作者: Phil_Libra 时间: 2022-11-27 21:57

darkclown 发表于 2022-11-27 21:42
帮忙找找那个帖子呗，我没找到

https://www.chiphell.com/forum.p ... page=2&mobile=1

要被网件坑死了，NAS里面文件废了大半，R7800用户注意啊

但是被归档了

作者: goat 时间: 2022-11-27 21:58

darkclown 发表于 2022-11-27 21:53
我不是用的samba啊，提给微软/intel他们会理吗？

直接找微软试试，至少比自己瞎摸解决方案强多了。
~~当然召唤个大佬直接指出哪里有问题更好~~

作者: darkclown 时间: 2022-11-27 21:58

Phil_Libra 发表于 2022-11-27 21:57
https://www.chiphell.com/forum.php?mod=viewthread&tid=1878038&extra=&page=2&mobile=1

要被网件坑死 ...

看不到帖子，你能讲讲吗？那个案例中为何文件损坏而tcp校验可以过？

作者: zhuifeng88 时间: 2022-11-27 22:04
本帖最后由 zhuifeng88 于 2022-11-27 22:31 编辑

脚本跑了10TiB测试(linux读写win11的共享目录, 网卡两侧都是mcx4421a, 交换机st5008f, linux生成1GiB随机数据, 本地计算crc32, 写入共享目录, 冲刷io buffer, 从共享目录读取刚刚写入的数据, 计算crc32并和之前的比对, 重复10240次), 没看到有明确问题, 比较怀疑是有其他方面影响

作者: jcd_chh 时间: 2022-11-27 22:25
我不知道我的案例有没有关系。前段时间从电脑往NAS上传了700G左右数据，win11 AX201-->群晖，都是单个十几个G的大文件，用的fastcopy开校验，传完可能有近100G的数据是过不了校验的

之前还有直接windows资源管理器传输，也出现过MD5不一致的情况
路由器是TP 6088，想不通到底是哪个环节的问题。

还是rsync好，公网龟速传过几个T的数据，MD5一点问题也没有。

作者: darkclown 时间: 2022-11-27 22:32
本帖最后由 darkclown 于 2022-11-27 22:38 编辑

zhuifeng88 发表于 2022-11-27 22:04
脚本跑了10TB测试(linux读写win11的共享目录, 网卡两侧都是mcx4421a, 交换机st5008f, linux生成1GiB随机数 ...

应该是我这边某一个环节错误率大而没被修正导致的，你那边应该不好观察到。。。

因为我这边做实验也比较慢，就先看看大家有什么说法，如果找到方向再进一步研究。

作者: darkclown 时间: 2022-11-27 22:34

jcd_chh 发表于 2022-11-27 22:25
我不知道我的案例有没有关系。前段时间从电脑往NAS上传了700G左右数据，win11 AX201-->群晖，都是单个十几 ...

你这个感觉跟我这很像啊，另外rsync是用什么协议的，ssh？那应用层有校验，和smb开加密效果应该一样了

作者: zhuifeng88 时间: 2022-11-27 22:40
本帖最后由 zhuifeng88 于 2022-11-27 22:41 编辑

darkclown 发表于 2022-11-27 22:32
应该是我这边某一个环节错误率大而没被修正导致的，你那边应该不好观察到。。。 ...

回头看了一下你的说明, 确实有一些误解, tcp checksum只有16 bit, 并不能保证"理论上不可能出现如图这种错误还通过的情况", 只能做到在错误完全随机发生的情况下, 把发生了错误, 但没有发现的概率降低到没有checksum情况下的1/65536, 如果原本错误发生率很高的话, 16bit的checksum显然是不够用的

作者: darkclown 时间: 2022-11-27 22:43
本帖最后由 darkclown 于 2022-11-27 23:03 编辑

zhuifeng88 发表于 2022-11-27 22:40
回头看了一下你的说明, 确实有一些误解, tcp checksum只有16 bit, 并不能保证"理论上不可能出现如图这种 ...

图中这种片段，400G的12000个文件，在各种实验中都稳定地出现5~8次，大概得多高的错误率能达到这种结果？我wireshark看基本没有包被错误重传

作者: zhuifeng88 时间: 2022-11-27 22:51
本帖最后由 zhuifeng88 于 2022-11-27 22:59 编辑

darkclown 发表于 2022-11-27 22:43
图中这种片段，400G的12000个文件，在各种实验中都稳定地出现5~8次，得多高的错误率能达到这种结果？我wi ...

假设完全均匀随机分布的情况下(虽然显然不是这样的分布), 但先这样估算吧, 就是只要发生327680-524288次错误就能导致5-8次错误通过tcp checksum的校验
400G数据大约182000000 802.11**帧, 大约就是需要0.2%的错误率就大致能达到这个数量级的tcp包内容错误并通过校验

作者: MaverickLee 时间: 2022-11-27 22:54
所以Teracopy和MultiPar是两个好软件

作者: xbcyl 时间: 2022-11-27 23:01
不大可能是SMB的问题。
我平时下载的电影和游戏（压缩包形式）都是通过smb上传到群晖，刚才看了一下，电影快60T，游戏快12T，还有各种照片、音乐、软件，杂七杂八加起来也有10几T，从来没遇到过文件损坏。如果才400G就碰到文件损坏，还怎么玩群晖。。。

作者: darkclown 时间: 2022-11-27 23:36
本帖最后由 darkclown 于 2022-11-28 00:06 编辑

zhuifeng88 发表于 2022-11-27 22:51
假设完全均匀随机分布的情况下(虽然显然不是这样的分布), 但先这样估算吧, 就是只要发生327680-524288次 ...

关键就是分布的问题，一般不是全随机，我记得以前看过有人分析过互联网上tcp的静默错误率，是一个很低的数，所以我第一反应是我这个情况不太可能。

不过你这么一说，我这个是burst的全随机错误，似乎概率更大？
按400G的N≈275,000,000个包中静默错误包的个数，要乘上几个因子：
1. burst阶段覆盖率，a=？
2. burst错误时不能影响mac/ip/tcp包头，按50/1500来算，避开这些的概率b=3%，不知道这样算对不

3. playload部分恰好通过checksum的概率，c=1/65536

要达到8个静默错误，需要a>6%，这个挺大的。

不过b是假设错误是由无线介质不稳算的，要是网卡或路由器程序bug，专门针对playload产生错误，那倒是有可能了啊。

作者: Phil_Libra 时间: 2022-11-27 23:38

darkclown 发表于 2022-11-27 23:36
关键就是分布的问题，一般不是全随机，我记得以前看过有人分析过互联网上tcp的静默错误率，是一个很低的 ...

你还是有线测测吧，别最后是Intel无线驱动的问题……

作者: darkclown 时间: 2022-11-27 23:48

Phil_Libra 发表于 2022-11-27 23:38
你还是有线测测吧，别最后是Intel无线驱动的问题……

我用的是win10自带的21.10.2.2版，我今晚升级下再测测。。。

作者: Dzzz 时间: 2022-11-28 00:17
WIN NAS开SMB共享用了这么多年，从来没有碰到过文件出问题的情况
虽然我不知道你这个是不是个例，但是拍脑门子想想我觉得不可能是SMB或者TCP的问题，这是非常严重的问题了，如果真出这种问题这协议早就废了

作者: zhuifeng88 时间: 2022-11-28 00:20
本帖最后由 zhuifeng88 于 2022-11-28 00:22 编辑

darkclown 发表于 2022-11-27 23:36
关键就是分布的问题，一般不是全随机，我记得以前看过有人分析过互联网上tcp的静默错误率，是一个很低的 ...

1, 你这个1500算的是以太帧, 802.11帧不同版本有差异, 但都在2350B左右(当然抓包驱动可以选择转换成以太帧显示, 或者保持802.11*帧显示)
2, b不是算3%, 而是应该算97%吧

作者: jcd_chh 时间: 2022-11-28 00:39

darkclown 发表于 2022-11-27 22:34
你这个感觉跟我这很像啊，另外rsync是用什么协议的，ssh？那应用层有校验，和smb开加密效果应该一样了 ...

rsync我记得应该开了ssh协议

作者: darkclown 时间: 2022-11-28 00:47

zhuifeng88 发表于 2022-11-28 00:20
1, 你这个1500算的是以太帧, 802.11帧不同版本有差异, 但都在2350B左右(当然抓包驱动可以选择转换成以太 ...

1. 原来无线帧更大啊
2. 确实不对，不过应该也不是97%
从已发生的静默错误段长度平均值1000来看（当然不知道原始长度），在每帧周期中能滑动的位置有2350-50-1000(因为不能把下一个帧头覆盖了)，那就是55%了，确实很高啊

作者: YoshinoSakura 时间: 2022-11-28 13:23
你这个问题我也遇到过，也是开加密解决了

作者: zhgna 时间: 2022-11-28 13:43
还有这种事？SMB传了至少几百t了吧，传输途中各种情况都碰到过，还没发现一起有数据丢失或错误的。

作者: ice0291 时间: 2022-11-28 13:53
我实在无力吐槽，这结论，好好把有线网部署起来。

作者: e3h4v 时间: 2022-11-28 14:19
你用有线吧，另外最好用交换机，路由器cpu满的时候可能会丢包

作者: darkclown 时间: 2022-11-28 14:20

ice0291 发表于 2022-11-28 13:53
我实在无力吐槽，这结论，好好把有线网部署起来。

这结论没问题吧，家庭内网，笔记本没人愿意用有线吧。。。

作者: FelixIvory 时间: 2022-11-28 14:25

darkclown 发表于 2022-11-27 21:42
帮忙找找那个帖子呗，我没找到

归档了，这个帖子我有印象。给文件加netgear的字头（字尾），帖主给网件反馈，当时就修复了。

作者: seagull06 时间: 2022-11-28 14:37
大概率是数据包被拆分重组失败导致，普通交换机并不支持巨型帧。

作者: darkclown 时间: 2022-11-29 18:00

seagull06 发表于 2022-11-28 14:37
大概率是数据包被拆分重组失败导致，普通交换机并不支持巨型帧。

怎么看是不是巨型帧？wireshark看着都是1500以内的

作者: qiu95 时间: 2022-11-29 18:47

darkclown 发表于 2022-11-27 21:58
看不到帖子，你能讲讲吗？那个案例中为何文件损坏而tcp校验可以过？

具体细节记不太清了，我记得是R7800的路由器如果开ap模式，一个网线接wan 另一个网线接lan，然后桥接。在传输大文件的时候samba文件的内容某些字符会被替换成WNDR之类的字符导致数据错误，当时猜测可能是内核bridge转发的时候发生了越界导致的？

作者: sunhaine 时间: 2022-11-29 18:51
你网络环境太差了,绝不可能是smb的问题

作者: yuechsh 时间: 2022-11-29 18:53
传输大量数据还是都挂在交换机下传输吧，路由器一过热就会有问题

作者: oling 时间: 2022-12-1 08:18
我SMB用这么多年了从来没有出错过，建议楼主先排查一下硬件看看吧。

作者: 皛羽控 时间: 2022-12-1 08:27
什么是静默损坏，先查查再用行不行？回到这个损坏问题我建议是更换硬件设备或者传输过程是否有干扰来排查，而不是把锅甩smb上。

作者: rivr 时间: 2022-12-1 09:45
暂时没发现出现这个问题，先关注一下，可能基于wifi的tcp并不是十分可靠？

作者: 港城钢铁侠 时间: 2022-12-1 09:54
不可能是SMB的问题，我工作中常用SMB往NAS上传大批量文件做备份，没有遇到过这种问题

作者: wspjy 时间: 2022-12-1 10:15

xbcyl 发表于 2022-11-27 23:01
不大可能是SMB的问题。
我平时下载的电影和游戏（压缩包形式）都是通过smb上传到群晖，刚才看了一下，电影 ...

游戏不好说，影视文件对数据错误的忍耐度很高，我迅雷下载电影常卡在99%不动，这时把文件改名直接拖进播放软件，一口气播完毫无问题。

作者: ExFan 时间: 2022-12-1 10:26
设备问题怪标准协议？挺逗...

作者: Juzi丶 时间: 2022-12-1 10:33
楼上很多人真是无知者无畏的样子...
可能没见过SMB开了加密之后传输故障主动报错和比如不开加密传一个图直接裂掉的情况吧

作者: jyjs3993 时间: 2022-12-1 11:10
这年头，真是防不胜防了

作者: jyjs3993 时间: 2022-12-1 11:16
另外，我发现如果内存不稳定，大容量文件也会造成某些错误。我在某笔记本上制作10GB的ISO文件，里面的文件总是会随机文件损坏。源文件是好的。
但是WINDOWS内存测试都是好的，也不会蓝屏，没有报错。
最后看了知乎的某帖子，换了内存后解决此问题。
从此，我就开始留意ECC了

作者: Juzi丶 时间: 2022-12-1 11:24
本帖最后由 Juzi丶于 2022-12-1 11:27 编辑

(, 下载次数: 68)
开启SMB加密传输文件出现错误然后直接中断

没事干整点测试

作者: hzrdog 时间: 2022-12-1 14:27

Juzi丶发表于 2022-12-1 10:33
楼上很多人真是无知者无畏的样子...
可能没见过SMB开了加密之后传输故障主动报错和比如不开加密传一个图直 ...

开了确实能知道出问题但解决不了问题

很多人的硬件情况确实不会碰到问题

作者: uuyyhhjj 时间: 2022-12-1 14:55

Juzi丶发表于 2022-12-1 11:24
开启SMB加密传输文件出现错误然后直接中断

没事干整点测试

别超频了，设备正常几百t，没问题的，设备不行开校验解决的也只是网路上的问题，端到端再校验一次错了能报告，你平时要是传十几g都出现数据异常，很明显有哪个环节异常导致，这论坛爱超频，很多人平时本地copy文件估计都hash不一样了也没发现

作者: ander22 时间: 2022-12-1 15:44
瞅了一眼WIN10 SMB加密的是不是高级网络设置的128位加密

好像是默认开的，还是在哪开

作者: jyjs3993 时间: 2022-12-1 21:15

ander22 发表于 2022-12-1 15:44
瞅了一眼WIN10 SMB加密的是不是高级网络设置的128位加密好像是默认开的，还是在哪开 ...

那个是身份验证加密，不是SMB数据加密。。。

作者: ander22 时间: 2022-12-1 22:19

jyjs3993 发表于 2022-12-1 21:15
那个是身份验证加密，不是SMB数据加密。。。

啊这，看看哪里开去

作者: cqykh 时间: 2022-12-1 23:55
赶紧去看看怎么开SMB数据保护……

作者: ander22 时间: 2022-12-2 02:46

好了跟楼上坐等看看有谁能教教WIN10怎么开

作者: goat 时间: 2022-12-2 03:11

Juzi丶发表于 2022-12-1 11:24
开启SMB加密传输文件出现错误然后直接中断

没事干整点测试

只碰到过不开100%炸，开了解决，最后结论链路问题，开也会炸么

这年头是要回归两头传完校验才能保真了么

作者: hlc1134 时间: 2022-12-2 07:14
本帖最后由 hlc1134 于 2022-12-2 07:20 编辑

感觉最可能是路由器问题。不知道lz在哪儿？是用的att还是spectrum 的ISP还是其他的？运营商给的路由器是个黑盒，里面会加很多他自己的东西，比如广告分析之类的。这种addons都非常非常不稳定。反正我用att的光猫问题挺多，最后我自己挂了一个asus路由器，运营商的路由器走透明模式后就很稳定。

其实可以在amazon很便宜买一个交换机，或者买一个大牌的路由器（如果lz只想用无线网），然后完全绕开运营商的路由器测试一下。

我今天用家用设备测了一下，PC和NAS互传，有线连接，中间经过了2个交换机，还有链路聚合，SMB强制开启加密，传了500G东西，没有报错。

反过来说，如果smb经常出错，然后开加密模式可以检测出传输错误然后自动报错。那就会有很多人收到smb的传输错误。这样早就炸开锅了，smb也不会活到现在。

作者: vva 时间: 2022-12-2 08:13
第一，smb如果按楼主测试，就这几下就都出错那问题就大了。这个东西都多少年了的技术
第二，就那英特尔无线网卡，你指望拿来正经干活？
第三，还不如找找硬件问题，你拿别的机器和设备测试测试？

作者: tedsun 时间: 2022-12-2 08:27
提示: 作者被禁止或删除内容自动屏蔽

作者: tedsun 时间: 2022-12-2 08:34
提示: 作者被禁止或删除内容自动屏蔽

作者: 皛羽控 时间: 2022-12-2 10:37
本帖最后由皛羽控于 2022-12-2 10:38 编辑

tedsun 发表于 2022-12-2 08:34
不是说smb协议有问题
而是说smb不抗干扰
在硬件有瑕疵的时候不报错

很多传输都不抗干扰要么为什么要有些加强的措施比如内存还有ecc，具体到SMB你也可以开启加密啊。

作者: rivr 时间: 2022-12-2 10:44

Juzi丶发表于 2022-12-1 11:24
开启SMB加密传输文件出现错误然后直接中断

没事干整点测试

这是什么原理呢？SMB不会自动坏包重传么？
不管怎么说，主动报错要比默默传个坏文件好多了

作者: 红色狂想 时间: 2023-5-4 17:47
看到撸主文中说网络环境无线网卡AX200……什么意思，难到是通过无线网络SMB共享数据的？

作者: zhao137314 时间: 2023-5-4 19:42
哈哈 xswl 无线网卡当服务器？

作者: u40jre 时间: 2023-5-4 20:43
没遇到过，pt 几十T 从nas传出来，稳如老狗

作者: dodd 时间: 2023-5-4 22:15

FelixIvory 发表于 2022-11-28 14:25
归档了，这个帖子我有印象。给文件加netgear的字头（字尾），帖主给网件反馈，当时就修复了。 ...

虽然是很久前的帖子，还是回复一下。

当年臭名昭著的网件r7800传文件损坏事件，我也是受害者之一。这个问题虽说只发生在ap mode下，但传文件错误率太高导致ap mode完全不可用。而且这个bug根本不是报告了马上就修了，而是拖了三四年之久，只不过之前chh的帖主发现问题晚网件已经快修好了。

可能是网件自己也觉得丢人，现在自家论坛上关于这个事件的讨论基本也都归档了，但外网上还留了一些零零星星的讨论。
https://www.snbforums.com/threads/r7800-data-corruption-when-in-accesspoint-mode.54744/

说起来我那台r7800也是命运多舛，本来就是r7500功能造假批量召回后换回来的，后来发现传输错误根本没法用，等后来bug终于修好的时候这型号都已经淘汰了。

作者: darksheen 时间: 2023-5-4 23:42
mark一下，以防万一我也在群晖上开启smb加密吧

作者: xmake 时间: 2023-5-5 01:49

darkclown 发表于 2022-11-27 22:32
应该是我这边某一个环节错误率大而没被修正导致的，你那边应该不好观察到。。。

因为我这边做实验也比较 ...

中间加个交换机，排出路由。

作者: darkclown 时间: 2023-5-6 18:55
本帖最后由 darkclown 于 2023-5-6 19:26 编辑

zhao137314 发表于 2023-5-4 19:42
哈哈 xswl 无线网卡当服务器？

有线错误率也不是0，更何况这么高的错误率可能还是固件问题导致的，谁也说不好哪天会遇到，smb一个网络文件传输协议，没校验日积月累导致人文件损坏没问题？

xswl，你哪天网上支付他给你来个http传输，内容也不校验，支付多个0是不是也是你用无线的锅？

作者: 啊对对对 时间: 2023-5-6 19:25
按道理来讲，802.11帧的CRC校验不至于这么脆弱呀，这锅无线链路真背不了吧，我更倾向于是路由器加料了

作者: zhgbbs 时间: 2023-5-6 19:33
mark下，这个错误率感觉有点吓人

作者: 葱花鱼 时间: 2023-5-6 22:06
本帖最后由葱花鱼于 2023-5-6 22:10 编辑

https://www.samba.org/samba/docs ... .html#SERVERSIGNING
虽然是samba的文档，但是根据描述在SMB 2.0以上server signing是默认协商开启的，相比于server smb encrypt选项，这个才是确保文件完整性的本职功能。

你可以试试通过Wireshark抓包分析一下看看Signing Enabled是不是为1，如果数字签名正常启用，理论上应该不会发生这样严重的文件数据错误才对。

作者: darkclown 时间: 2024-12-26 10:38
本帖最后由 darkclown 于 2024-12-26 10:40 编辑

葱花鱼发表于 2023-5-6 22:06
https://www.samba.org/samba/docs ... .html#SERVERSIGNING
虽然是samba的文档， ...

default和auto都不是强制要求签名，是跟客户端协商的，但几乎所有客户端默认都不启用签名，目前好像只有win11 24h2更新改成了默认启用

作者: huihuige 时间: 2024-12-26 15:34
好帖子
马克了
但是是不是挖坟了？

作者: yangxin51357 时间: 2025-1-5 20:29
我的i350网卡出现了局域网文件传输频繁文件校验错误,我测试了两台机器,网卡对网卡校验,没有错误, 怀疑硬盘坏道,扫描了一圈,性能很好 ,没有任何异常..怀疑网卡驱动,升级到了最新版驱动,结果一测试..仍然在文件SMB传输后出现了校验不通过的问题..
然后我想起了内存可能有异常.掏出启动盘一扫描,果然一根内存条出现坏道......... 研究了一下内存顺序拔掉一根后,检测通过...

所以,遇到SMB传输文件校验错误需要从网卡端、硬盘端、内存端分别检测

作者: yin19991999 时间: 2025-1-5 20:59
内存问题，我之前换文件还是使用了朗科垃圾tf卡导致的，的，复制的raw图片随机有竖条横条

作者: 蒙古国海军司令 时间: 2025-1-7 11:38
之前遇到过这个问题，我这边多台机器都是 syncthing 同步，所有文件都会算校验

作者: whyu 时间: 2025-3-9 19:56
本帖最后由 whyu 于 2025-3-9 19:58 编辑

我这边也遇到同样的问题了，群晖NAS映射到本地，本地是macOS 13.6，几个月前时间机器提示备份损坏，需要全部抹掉，一开始没当回事，结果最近备份损坏得越来越频繁，一周就损坏一次。最近从共享上下载照片，每几张就有一张是损坏的，有的是只有上半截其余全是灰色，有的是整张图错位，有的是颜色通道混乱。用MD5工具直接计算共享文件的MD5，每次结果都不一样

，按照楼主的方法开启了SMB加密，用虚拟机里的Win 11测试，结果250MB的文件，没有一次能传输成功。

问题原因还在调查中。

作者: anren4 时间: 2025-3-9 19:58
同步还是用rsync算了

欢迎光临 Chiphell - 分享与交流用户体验 (https://www.chiphell.com/)