kecho05

root@ENAS:~# wget --compression=auto -O /dev/null https://ca.unraid.net/assets/feed/applicationFeed.json --2025-10-16 09:55:09-- https://ca.unraid.net/assets/feed/applicationFeed.json Resolving ca.unraid.net (ca.unraid.net)... 172.67.69.176, 104.26.3.117, 104.26.2.117, ... Connecting to ca.unraid.net (ca.unraid.net)|172.67.69.176|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/json] Saving to: ‘/dev/null’ /dev/null [ <=> ] 1.94M 1.67MB/s in 1.2s 2025-10-16 09:55:11 (1.67 MB/s) - ‘/dev/null’ saved [20395759]

sometimes at homepage/docker i can see the error message above but actually dockers like qbittorrent runs well, still can open x.x.x.x:8080 which is qbittorrent's webui. after restart whole system everything works well but after days or hours the error happens again. i check the logs then found some SQUASHFS error, maybe it is the reason? i upload two logs file, all of them have same problem and same records on logs. thank you very much for helping me on this. enas-diagnostics-20240602-1312.zip enas-diagnostics-20240606-1010.zip enas-syslog-20240602-0512.zip enas-syslog-20240606-0210.zip

在系统后台无法访问docker页面了，错误页面如下 但是直接访问ip:8080是可以打开qb的页面，说明docker是在运行状态的 平时只开了两个docker，一个静态服务，一个qb 相比以往，这次只是让qb校验了几个比较大的种子。 然后观察后台日志，昨天晚上出现了一些报错 Jun 1 20:50:23 ENAS kernel: SQUASHFS error: xz decompression failed, data probably corrupt Jun 1 20:50:23 ENAS kernel: SQUASHFS error: Failed to read block 0x2b77b70: -5 Jun 1 20:50:23 ENAS kernel: SQUASHFS error: xz decompression failed, data probably corrupt Jun 1 20:50:23 ENAS kernel: SQUASHFS error: Failed to read block 0x2b77b70: -5 Jun 1 20:50:23 ENAS kernel: SQUASHFS error: xz decompression failed, data probably corrupt Jun 1 20:50:23 ENAS kernel: SQUASHFS error: Failed to read block 0x2b77b70: -5 Jun 1 20:50:23 ENAS kernel: SQUASHFS error: xz decompression failed, data probably corrupt Jun 1 20:50:23 ENAS kernel: SQUASHFS error: Failed to read block 0x2b77b70: -5 Jun 1 20:50:23 ENAS kernel: SQUASHFS error: xz decompression failed, data probably corrupt Jun 1 20:50:23 ENAS kernel: SQUASHFS error: Failed to read block 0x2b77b70: -5 Jun 1 20:50:23 ENAS kernel: SQUASHFS error: xz decompression failed, data probably corrupt Jun 1 20:50:23 ENAS kernel: SQUASHFS error: Failed to read block 0x2b77b70: -5 虽然影响不是很大，而且重启以后一切正常。 但是我仍然想知道出现这个问题的原因到底在哪里，如果可以的话，怎么去避免它 enas-diagnostics-20240602-1312.zip enas-syslog-20240602-0512.zip

hi there, I had changed a new 10t disk instead of old 2t disk, because old disk have a lots of errors. My array has one nvme ssd disk and 2 sata disk (previous are 10t+2t and now 10t+10t) My nas have enough dock so i first add new 10t disk to my array and use rsync command to transfer data. During the transfer there are a lots of input/output error 5 and the result is the command only transferred ~1.2TB data to new disk (which should be around 1.6T data according to the useage) Now i found a lots of errors in logs and i think the error happens when my docker-qbittorrent run the recheck for the red seeds. if i stop the recheck, no more errors. Attached are my log and diagnostics file. Thanks in advance for any help with this issue. enas-diagnostics-20240421-2141.zip enas-syslog-20240421-1341.zip

已根据上一条的回复增加了pcie禁用参数 这次启动系统以后，xhci_hcd 0000:00:0d.0: PCI post-resume error -19!的报错依旧存在，看来其跟我的硬件有关，但是似乎它并不是造成问题的核心原因，个人认为可以暂时排除这个因素。 这次重启系统以后我成功复现了报错 附件是日志和诊断文件 可以看到21:56:39起不断报错，这是因为我在等待系统启动并稳定运行后，开启了docker-qbittorrent的校验文件功能，因为之前2t的硬盘rsync过来的文件有一些是不完整的，这也导致了我qb部分红种的情况，我想让qb把红种校验一遍，然后重新下载缺失部分。 如此推断，很可能是qb的校验行为导致的日志里出现的大量报错，而且这个报错出现的时候，也会反过来影响qb的校验速度。 待qb校验完现有红种以后此问题就会消失？ 还是说以后只要qb校验文件就会出现这个情况？ 暂时还不清楚，不过以前肯定是没有这个问题的。 如果大佬们有猜想的解决方案，我也乐于一试，如果等校验完毕后仍会报错，我也会回来提供新的日志和诊断文件 enas-syslog-20240420-1414.zip enas-diagnostics-20240420-2214.zip

更新几条错误日志记录，这期间除去qb下载，没有做其他操作

已排查了供电、sata线等区域，暂时没有发现什么异常（除了更换的硬盘，一切均与前几天一致，更换上去的硬盘也是一个全新的健康硬盘，我也尝试过更换硬盘插槽） 我暂时定位到了一个100%复现的错误，我也不知道是对是错 附件这是系统重启的日志 可以发现系统在启动的时候这里有报错 然后我去设备列表里看，这个设备代码好像是usb控制器（下图红框）但是我的设备目前只有一个正在使用的usb设备（即unraid系统盘，下图蓝框） 我也不知道这是不是后续sata硬盘错误的导火索（刚才又出现了sata硬盘的大量错误，与一开始的提问类似，sata一会link到6.0Gbps，一会link到3.0Gbps，一会儿link到1.5Gbps，最后还出现了文件在nfs共享中访问不到的问题，后续重启又好了） 附件是nas重启到能够web登录的日志和诊断文件，不知道能否有帮助 后续我会在硬盘再次出现错误的时候，上传新的诊断和日志文件。 enas-syslog-20240420-1155.zip enas-diagnostics-20240420-1956.zip

之前的阵列是2t+10t硬盘，那块2t的硬盘频频报错，于是买了一块新的10t硬盘 然后用rsync把2t数据转移到新的10t硬盘的时候频频报错（出现大量input/output error 5）的错误 最后2t硬盘显示1.69t的数据只转移过来1.2t，不是什么特别重要的数据我也就拉倒了。 但是现在阵列是10t+10t硬盘，smart也完全是健康的情况下 在日志里发现如下错误 请问这个问题该如何排查？

顺便问一下，默认unraid设置中的这个等待的时间单位是啥？秒？分钟？小时？

谢谢大佬，这就去试试看

目前的状态：一共4个硬盘槽位，槽位1和3分别装了硬盘A和B，没有使用校验盘。 想达到的状态：把槽位3的硬盘B更换为硬盘C，使得原来1-A、3-B变成1-A、3-C，依旧不使用校验盘。 问题： 我应该如何转移数据及挂载硬盘？

又出现了一段新的错误 伴随着这段错误的出现，我的整个文件共享也没了（磁盘序列还在） 请问这也是磁盘IO的问题吗？（已经删掉了intel sriov插件） Mar 31 14:01:52 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:02:03 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0. Mar 31 14:04:20 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:06:52 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0. Mar 31 14:11:41 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:11:46 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0. Mar 31 14:15:23 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:15:33 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0. Mar 31 14:17:49 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:18:12 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0. Mar 31 14:20:16 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:20:23 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0. Mar 31 14:21:29 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:21:52 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0. Mar 31 14:22:00 ENAS dhcpcd[25119]: eth0: REPLY6 received from fe80::d635:38ff:fe75:b700 Mar 31 14:22:00 ENAS dhcpcd[25119]: eth0: adding address 240e:388:5f18:3d00::3d2/128 Mar 31 14:22:00 ENAS dhcpcd[25119]: eth0: renew in 1605, rebind in 2568, expire in 3210 seconds Mar 31 14:23:58 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:29:58 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0. Mar 31 14:30:55 ENAS kernel: shfs[27961]: segfault at 14b86491bbf0 ip 000014b87178f9c7 sp 000014b8703edb88 error 4 in libc-2.37.so[14b87164d000+169000] likely on CPU 3 (core 3, socket 0) Mar 31 14:30:55 ENAS kernel: Code: 48 01 d0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 c4 41 01 ef ff 89 f8 09 f0 c1 e0 14 3d 00 00 00 f8 0f 87 29 03 00 00 <c5> fe 6f 07 c5 fd 74 0e c5 85 74 d0 c5 ed df c9 c5 fd d7 c9 ff c1 Mar 31 14:31:01 ENAS avahi-daemon[25993]: Registering new address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.*. Mar 31 14:31:10 ENAS avahi-daemon[25993]: Withdrawing address record for fdba:73f9:cf63:dd40:aab8:e0ff:fe02:b531 on eth0.

目前整个unraid系统还是可用的，但是暂时不知道应该把错误定位到哪里 提问是想知道错误到底在哪，方便后续的维护（换u盘 or 换硬盘） 请主要看Mar 29 18:00及以后的日志（之前是重启了一下系统） 我确实有个smart不那么健康的硬盘（disk2），但是想着既然能用就先用着再说了 看日志好像错误也跟硬盘无关，那是U盘的问题？还是网络的问题？（日志里好像提到过） Mar 29 17:58:37 ENAS kernel: i915 0000:00:02.0: [drm] *ERROR* AUX USBC2/DDI TC2/PHY TC2: did not complete or timeout within 10ms (status 0xad4002ff) Mar 29 17:58:37 ENAS kernel: i915 0000:00:02.0: [drm] *ERROR* AUX USBC2/DDI TC2/PHY TC2: did not complete or timeout within 10ms (status 0xad4002ff) Mar 29 17:58:37 ENAS kernel: i915 0000:00:02.0: [drm] *ERROR* AUX USBC2/DDI TC2/PHY TC2: did not complete or timeout within 10ms (status 0xad4002ff) Mar 29 17:58:37 ENAS kernel: i915 0000:00:02.0: [drm] *ERROR* AUX USBC2/DDI TC2/PHY TC2: did not complete or timeout within 10ms (status 0xad4002ff) Mar 29 17:58:37 ENAS kernel: i915 0000:00:02.0: [drm] *ERROR* AUX USBC2/DDI TC2/PHY TC2: did not complete or timeout within 10ms (status 0xad4002ff) Mar 29 17:58:37 ENAS kernel: i915 0000:00:02.0: [drm] *ERROR* AUX USBC2/DDI TC2/PHY TC2: not done (status 0xad4002ff) 和 Mar 29 17:59:02 ENAS root: Error response from daemon: network with name eth0 already exists enas-syslog-20240330-0318.zip enas-diagnostics-20240330-1127.zip

首先我不是很懂。 但是我看你这里container port后面都没有值，是不是没有映射成功啊？ 点后面的编辑按钮，把container port的值加上试试看呢？

哈哈，我也是晕乎乎的，我最近出现的问题都很奇怪（今早我改了一下qb的密码，然后停了docker再打开，qb的webui就打不开了。。。） 有没有一键恢复网络默认配置的方法啊

很奇怪，在我的docker设置里，这一项ipvlan处于灰色的不可选状态。

首先这是我的网络拓补图： 出现的问题主要表现在手动设置dns为旁路由APTV的ip以后网络依旧不通，无法更新插件，应用界面也出现如下错误提示。（当然根据错误提示改了DNS以后依旧没有任何作用）。重启、关机再开机，这个问题依旧存在。与此同时，局域网其他设备将网关和dns指向APTV后可以正常打开各类网站。 打开unraid终端使用ping和traceroute命令测试连通性，报错如下： 因为看到最初ping的解析是一个ipv6地址，于是怀疑原因是网络设置中使用“ipv4+ipv6”这里，于是将网络改成“仅ipv4”和“仅ipv6”分别测试，网关和dns依旧指向旁路由ip： （这个怀疑其实不成立，因为在之前改dns的方法可用时，“ipv4+ipv6”的设置是没有问题的，但为了控制变量，还是测试一下吧）。 【仅ipv4】： 这是dns服务不通的意思吗？那我把网关指向192.168.31.5，dns1设置成8.8.8.8，dns2设置成8.8.4.4 一模一样的报错，问题并没有得到解决。 【仅ipv6】： 保存……哦豁……NAS失联了……（这不废话吗，ipv4被我关了，只能通过ipv6的地址才能访问后台啊），但是我的小米路由器无法在后台查看分配的ipv6地址。这可怎么办。。。 想着要么用ssh登录看看，结果ssh 192.168.31.1被无情的refuse了（呵呵，小米AX6000真有你的），没办法，只能把NAS关机，从U盘配置文件里下手，看能不能把它救回来。（关机方法：按一下电源键，大约等30秒，硬盘停转就关了。直接拔U盘怕是会有各种灵异事件，请勿轻易尝试） 在U盘里看到有个/config/network.cfg文件（感谢unraid开发大佬们良好的起名习惯，真是一目了然啊），里面的配置跟我猜想的差不多： 然后我把红框内的内容分别改成ipv4和yes（其他的也不太会改，就先保持不变），重新把U盘插上，开机。 等待的过程比想象中久一点（大概3分钟），在路由器后台刷到了NAS的MAC地址，然后用对应的ip成功连回了NAS（真不容易），再把ip再改回静态和原来的数值，这个小插曲暂且告一段落。 回到最初的问题，因为暂时没有头绪。只好把网关和dns改回路由器，可以看到改回去以后的nas是可以正常上网的（emmm，但是更新插件什么的嘛……还是要上科技才行）： （小强你别跑，刚才就是你不让我ssh的是吧？！） 在各种设置页面之间乱点（但是没乱改），and 网上冲浪到处搜索’ping & traceroute不通‘，’name or service not known‘之类的关键字，突然看到一个回答提到了VM啥的，，，嗯？VM？欸？对哦，我好像改过它的设置。 进入unraid - 工具 - 虚拟机 页面，虚拟机，启动（emm，事实上我的虚拟机列表是空的，也从来没有添加过虚拟机）那就不是这里，虚拟机，关闭。 但是这一点激起了我前两天的某个回忆片段。那时候在查询unraid虚拟机硬件直通的内容（为将来的折腾做准备），考虑到我的设备有四个网口，我想在保留第一个网口（eth0）作为unraid的管理口的情况下，把剩下三个网口直通给未来可能有的虚拟机使用，于是就点开了 unraid - 工具 - 系统设备这个页面。 我记得某个教程是说如果想把硬件直通给虚拟机使用，则应该在对应的pcie设备或IOMMU组前面打勾。 <回忆开始>我想起几天前我也是在这个页面，勾选了我的网口2（对应eth1），然后点了保存，然后unraid系统提示我要重启以后才能生效，可那会儿我正在用docker的qbittorrent下载，并不是很想重启，我就又取消勾选它，又点了一次保存，然后unraid还是提醒我需要重启才能生效。。。那个黄色banner就一直在我眼前飘。。。我想着我又没搞什么大变化，干嘛非要我重启，就一直忍着，大概过了一天，才重启设备，那个banner也就消失了。<回忆结束> 这个时候我又回到页面的最下面，看我这里的网口选项，突然我发现一个异常：我的网口1（eth0）的绑定怎么没有了？（我记得它应该是灰色不可选的状态，且默认应该是勾选中的状态才对，否则我的nas用谁来连接呢，可是现在却是可以勾选的状态？？这又是怎么回事？？） 难道旁路由不通的问题跟它有关？我是否应该把它改回勾选状态？带着这个疑问，我勾选了第一个网口（也就是红圈圈住的地方），然后保存并重启了设备。。。 又失联了…… 失联以后我才反映过来，刚才那不是设置设备直通的页面吗？我直通了eth0，那eth0就不能给unraid用了，很正常啊，逻辑闭环了这是。。。再加上我之前设置网络的时候为了把另外三个网口分出来，把eth0的绑定和桥接功能全部关闭了，也就是说其他三个网口也是不能用的状态。这下我知道，我又把NAS扔到了一个无法触及的荒原。。。。无话可说。。。怎么办，继续按电源键关机+拔U盘呗。 再一次凭直觉找到了/config/vfio-pci.cfg文件，而且还看到了一个vfio-pci.cfg.bak文件，看了看这俩文件的修改日期，其中之一正是我刚刚改完配置重启又失联的时间，另一个则跟我几天前勾选网口2的时间大致相同，我感觉应该就是它们了。查看到vfio-pci.cfg的内容是‘BIND=0000:01:00.0|8086:125c’，而vfio-pci.cfg.bak的内容是‘BIND=0000:02:00.0|8086:125c’，这不就是我网口们的pcie设备地址吗，于是把vfio-pci.cfg的内容改成‘BIND=0000:02:00.0|8086:125c’，保存，插回U盘，开机，真不容易，我的NAS又联回来了…… 至此，我关于旁路由不通的问题折腾到现在，走了很多弯路但是又回到了原点。我觉得我这个折腾的经历很值得分享出来（毕竟一晚上搞失联两次，也算是少见了）。我的经验就是失联了并不可怕，冷静想想，总能找到问题出在哪里。 但是我最初的问题依旧没有被解决，我还是怀疑它跟我前几天改pcie直通相关的设置有关（因为在改它之前，我是可以正常使用旁路由的，中途nas也没有重启过，docker只有一个qbittorrent在正常使用，另外有一个半成品docker配置了一半也还没用），所以我在最后上传了我的诊断资料，还望有了解我这个案例核心问题的大佬指个路，不胜感激 enas-diagnostics-20240311-2051.zip

unraid 和 nas 纯新手，昨天才把系统跑起来的那种，但不算纯小白，还是有一点网络知识的（但不多，可以学） 提问主要是看了@JackieWu大佬的博客，目前有几个问题想咨询一下 首先是看了博客的文章一《存储目录结构说明》文章二《详解FUSE-SHFS、I/O问题和解决办法》，对unraid的文件读写有一些疑惑。 问题一：如果用文章二里的“方法三”绕过/mnt/user路径，是不是可以理解为我可以直接用“disk share”的方式代替“user share”？（我认为的答案是：可以，这样可以提升io效率）那么，代价是什么呢？会导致奇偶校验等功能不可用吗？ 问题二：假设上面的逻辑成立，那么下面两种情况： -->在user share模式里，假设我有 /user/movie 和 /user/data 两个目录，它们在一个2盘的阵列中，/movie 的真实位置在disk1，/data 的真实位置在disk2 -->在disk share模式里，假设我也有 /disk1/movie 和 /disk2/data 两个目录 那么： 如果film体积越来越大，即将超过disk1 的容量，会发生什么？（我猜想的答案是：在user share模式下，系统会在data2里也建立/movie文件夹，继续存多出来的文件；而在disk share模式下，只会告诉我disk1 满了，并没有办法继续存多出来的文件。） 继续看了博客的文章三《应用商店代理》和文章四《将 Docker 的自定义网络绑定到第二个网口》，有下列疑问： 问题三：两个网口的解决方案最终实现的时候，需要将nas的两个网口都用网线接到路由上吗？还是说只在软件层面设置就可以了，无需物理连接？ 问题四：我对文章四补充说明的内容产生了更大的疑惑，也许是对文章中提到的arp flux问题理解不够。但是如果docker使用的网口是另一个网段（假设为192.168.2.x），那它不就成了主网络（192.168.1.x）的子网络了吗？那么根据网络层级关系，我一个主网络的设备（192.168.1.x）不就访问不到docker（192.168.2.x）上的服务了吗？ 问题五：基于问题四而来，假设我的unraid是（192.168.1.2，网关192.168.1.1），有没有一种方法让unraid里的docker服务ip变成如下形式【docker1 192.168.1.201 网关192.168.1.1】【docker2 192.168.1.202 网关192.168.1.254】【docker3...】。可以达到的话，该怎么设置？（我的unraid机器上有四个网口，网口1连了路由，网口2-4空闲） ps:说白了我想达到的效果是unraid的网关是旁路由，达到更新系统和下载docker的目的，另外让部分docker的流量不经过旁路由，（但是有些docker也需要去旁路由） 问题六：（其实跟unraid无关了，但也属于网络问题，就顺便写在这里了，看谁正好遇到相同情况吧。） 背景：我家路由器用的是小米AX6000，现在在我的网络中起到一个网络中枢的作用，它一方面PPPOE拨号上网（光猫桥接）、一方面提供WiFi功能、也是家里的DHCP服务器、然后又有线连接了电视盒子和nas。 现象：WiFi下传文件非常慢（只有几十到几百k/s），尝试更换过WiFi广播的信道，也没有改善。有线连接时传文件的速率就正常多了。（WiFi开启了2.4G/5G信号的ssid合并功能）有没有谁知道该怎么解决