JackieWu

可能是中文语言插件的问题，你可以尝试卸载中文语言后重新安装。 参考：

你可以尝试使用下面的方法对网卡进行 IOMMU 强制分组，设置好之后再去尝试启动虚拟机。 设置 - 虚拟机管理：将“PCIe ACS 覆盖”和“VFIO 允许不安全的中断”按图片的说明进行设置，设置之后重启 UNRAID 。

你遇到的应该是 macvlan_broadcast 问题，简单来说你可以通过以下两种方法去解决： 将 docker 自定义网络类型由 macvlan 改为 ipvlan 。 给 docker 自定义网络绑定另一个物理网口。 具体方法参考：unRAID macvlan 失联问题解析（以及如何给Docker分配独立网口），6.12.4 关于失联问题的解决办法以及相关更新说明。

日志里面没有发现比较明显的报错，明前还不太清楚具体是什么造成的，现在你那里还依然有这个问题吗？

你可以参考这篇文章里面《为什么unRAID下载/拷贝文件时CPU占用高：详解FUSE-SHFS、I/O问题和解决办法》关于 UNRAID 阵列中的数据聚合功能的逻辑和作用（SHFS），可能会帮到你。

应该是 docker.img 镜像文件的文件系统出错了，处理方法可以参考：常见问题-8：Docker 服务无法启动/容器消失的解决办法。

思源笔记（部署方法参考这里） 其他参考 V2EX 的帖子： 有没有可以私有化部署的类似 notion 的笔记软件? 请问一下对于 notion、语雀、wolai、印象笔记等这些你们是什么看法或者有什么可以推荐？

一般是本地网络问题造成的，也有可能是 UNRAID 的服务出了问题（但是几率相对较小）。

这个问题很经典，正好借助这个话题来给看到这个帖子的朋友们分享一下其中的逻辑。 1. 起因 使用 SMB 去编辑文件提示没有权限的情况，很多时候都是由于用户组没有可编辑权限导致，而如果你访问的这些文件属于某一个 Docker 应用所创建，那么很有可能是由于 UMASK 变量所设置的值不包含用户组的可编辑权限，从而导致了 SMB 用户所属的用户组权限不足，进而无法编辑文件。 首先，大家需要对 Linux 的文件权限有一个大概的了解，这里我提供一些参考的资料给大家自行去学习——参考资料-1，参考资料-2（你也可以自行搜索资料去了解）。 其次，当我们使用 SMB 协议去访问 UNRAID 上的文件时，我们需要有相应的权限才能够对文件进行增删改查，很多时候这个权限主要取决于使用 SMB 的这个用户的所属用户组权限，用户组权限不够就会有权限不足的提示。 接着，如果你需要编辑的文件是某一个 docker 应用所创建出来，那么你就需要首先考虑安装这个 docker 应用时有没有配置 UMASK 变量（并不是所有的 docker 都会需要配置 UMASK 变量）。如果有配置的话，那么你需要检查变量的值是能让用户组有编辑的权限（关于 UMASK 的简单解释可以看这里，同样的你也可以自行搜索资料去了解）。另外对于新手朋友，我也推荐你了解一下 UNRAID 上正确安装 Docker 的步骤，具体的文章请看本末尾的参考资料。 2. 实际例子 这里我以 qBittorrent 为例进行讲解，因为这个应用绝大多数的 NAS 用户都会进行安装。下面是一个从 APPS 安装的 QB 应用的配置参数（Linuxserver/qbittorrent），大家需要重点关注的是 UMASK 这个设置（关于 PUID/GUID 的说明请看末尾的参考资料）： UMASK 设置为 022 这个值之后，假设我利用 QB 下载一个文件，那么文件被创建出来后的默认权限是： 文件夹：rwxr-xr-x 文件：rw-r--r-- 也就是说，只有文件拥有者有完整的【读写】权限（rwx），组或者其他用户只有【读】权限（r--），这也就意味着当你通过 SMB 尝试去对 QB 所创建出来的文件进行编辑的时候是没有权限的，因为使用 SMB 协议的用户所在的组权限不足（如下图），原因就是由于 UMASK 的值导致： 如果我此时使用以下命令，为 QB 下载目录内的所有文件/文件夹添加所属组可编辑权限（w）： chmod -R g+w ./downloads 然后我再进行编辑的时候就没有权限不足的提示了： 如果我将 UMASK 的值设置为 002 ，那么此时所属组的权限包含了读写的权限（rw）： 此时使用 SMB 协议去编辑也没有权限不足的提示： 所以，当我们通过 SMB 去对 UNRAID 上的文件进行编辑时如果出现权限不足的情况，很多时候就是由于用户组权限不够导致。 3. 解决办法 首先，你可以将 Docker 变量中的 UMASK 的值设置为 002 ，这样 docker 应用创建出来的文件可以被 SMB 的用户进行编辑。 接下来，如果你需要对现有文件的权限进行调整，那么你可以借助 Fix Common Problem 插件处理，参考这里。 另外，你也可以使用 chmod 命令进行单独的处理，此方式比较适合处理 appdata 内的文件。因为默认情况下 appdata 内存储着各种 docker 应用的配置文件夹，有些 docker 应用需要有特定的用户权限才能正常运行，所以不能随便利用工具对所有 appdata 内的文件进行统一的改动，具体的说明看这里。 4. 其他参考资料 关于 PUID/GUID、PID/GID 这些变量的作用大家可以参考这篇《新手教程：如何在 unRAID 上正确安装 Docker》，顺便也了解一下如何正确安装 docker 应用和解决文件权限问题。 关于 UNRAID 上 SMB 用户认证的相关资料大家可以参考我前些年我的一篇文章《unRaid SMB 共享：基于Windows 10 下的 SMB 问题深入分析及解决方式》。 关于 UNRAID 上配置 SMB 的内容可以参考《新手教程：unRAID 开启 SMB 的其他方法》。 除开 UNRAID，你也可以参考我的另一篇关于 SMB 的文章《Windows 10/ 11 下安全并正确地使用 SMB 共享》。

一般是网络问题，如果挂了代理的话，建议换个代理看看。 参考：

Good to hear that. By the way, rcu_nocbs=0-11 is for AMD CPU ？

UNRAID 的正版密钥是与 U 盘绑定的，所以你将 U 盘放到任何设备上都不会影响 UNRAID 的认证。 一般来说将 U 盘放到新设备上不需要设置什么东西，确保主板能够正常引导 U 盘加载 UNRAID 系统就行，进到 UNRAID 后再根据实际情况调整相应的配置就可以了。

转移文件的话可以使用 rsync 命令或者使用 unBALANCE 插件，参考： unRAID 通用文件传输工具 —— Rsync 命令 unBALANCE 文件转移工具使用方法和应用案例介绍 提示空间不足可能是由于“最小可用空间”的设置造成的，我之前有解释过这个设置的逻辑，参考：

多数是硬件兼容性问题，如果有第二个 nvme 插槽的话你可以尝试更换到另一个插槽试试看。 另外你也可以尝试更换 UNRAID 的系统版本进行尝试。

“清理”（scrub）用于检查数据的完整性。执行清理时会检查 ZFS 缓存池中的所有数据，以验证其校验和是否正确。 在 ZFS 文件系统下，当写入数据时，ZFS 文件系统会计算文件的校验和并将其与文件数据一起写入。当以后读取该数据时，ZFS 重新计算校验和。如果校验和不匹配，意味着检测到一个或多个数据错误。执行清理后 ZFS 将尝试自动纠正错误，从而防止数据损坏和数据丢失的问题。

不需要重置。默认的 UNRAID 共享文件夹完全可以自己创建，这几个文件夹没什么特别的，你可以参考我这里的文章去理解默认文件夹的作用：Unraid 默认共享文件夹的作用以及分配方法的说明。

CPU 资源是共享的，并不会出现将某个 CPU 核心给到虚拟机之后，其他的虚拟机或者说 Docker 之类的服务就不能使用这个核心了；同时 CPU 资源也是动态的，即使你将所有的 CPU 核心都给到某一个虚拟机，当这个虚拟机闲置的时候，CPU 资源也同时会释放出来给到其他的服务去使用。 但内存是定向分配的，也就是说如果你给某一个虚拟机分配了 4G 的内存，那么 UNRAID 会直接将这 4G 的内存给到虚拟机，UNRAID 上的可用内存就会减少 4G，因为其他的服务不能去占用这 4G 的内存。 关于内存的参考资料：unRAID上我需要多大的内存？

我没尝试过，但是之前论坛里面有过相关的主题，你可以参考这个主题的内容：

thanks for sharing !

pci=nommconf 应用后重启。

解决了吗？

看一下你的 Media 文件夹属性设置（点击“共享”页面下的 Media 文件夹名字），如果“最小可用空间”的值设置得太大，将会出现你截图中的“shfs：share cache full”的报错。 关于“最小可用空间”（Minimum free space）的说明 需要解释的是，“最小可用空间”并不控制可用空间的大小，而是控制硬盘必须有多少可用空间才能被选中用于写入新文件。举个例子，假如将“最小可用空间”的值设置为 100G ，那么当有新的文件写入到阵列里面时，UNRAID 依据你对共享文件夹所选用的“分配方法”（Allocation method）和“拆分级别”（Split level）去选择阵列中某一个硬盘存储这个文件，即使你写入的这个文件只有 1KB 大小，被选中硬盘的可用空间必须要大于 100G 才会被选中用于写入文件。 那是因为 UNRAID 在接收到一个文件写入请求时，UNRAID 并不知道这个文件有多大，UNRAID 能做的就是根据分配方法和拆分级别选择一个阵列中的硬盘去存储这个文件。但假如说这个硬盘的可用空间已经不足以存储这个文件，那么最终就会出现硬盘空间不足的情况，也就只有这个时候 UNRAID 才知道所接收的文件大小大于硬盘的可用空间。 “最小可用空间”（Minimum free space）需要设置成多大的值 默认情况下，新创建的共享文件夹会按硬盘大小的 10% 去自动配置“最小可用空间”的大小。根据官方的建议，你可以将值设置成你曾经传输过的最大的一个文件的大小，例如你曾经传输过的最大的一个文件大小是 50G ，那么你可以将“最小可用空间”的值设置为 2 倍于此文件的大小：2 x 50G = 100G ，这样即使你偶尔传输了一个比之前传输过最大文件还要大一点的文件（但不超过 100G ），也不会出现楼主所出现的问题。 官方 WiKi 说明文档：Minimum free space 参考案例：

可以，不会引出什么问题。

建议你可以尝试删除 U 盘内 config 文件夹下面带有 “network” 字眼的网络配置文件来重置 UNRAID 网络设置，如果你熟悉 linux 命令的话也可以在系统内删除（对应在 /boot/config 目录下）并重启 UNRAID。删除并重启 UNRAID 之后系统会自动使用 DHCP 获取 IP 地址并创建默认的网络设置。 请记得先备份 U 盘再进行尝试。

一般是兼容性问题（M2 主控与 UNRAID 内核的不兼容），这种情况比较容易出现在光威和阿斯加特的 NVME 存储上，此问题常常在升级 UNRAID 系统版本后出现。 我之前帮一位朋友升级系统后他的阿斯加特 NVME 内存识别不出来了，最后只有回退到 6.9.1 版本才能正常识别，所以建议你可以考虑回退一下系统。 参考：