- 1. Unraid Server介绍
- 1.1 Unraid 官网及中文帮助索引大全
- 1.2 Unraid Server简介
- 1.3 Unraid Server 应用场景
- 1.4 Unraid Server 软件特点
- 2. Unraid Server组成部分
- 2.1. 网络附加存储
- 2.2. 应用服务器
- 2.2.1 应用服务器Docker介绍
- 2.2.2 Unraid Docker 引擎
- 2.2.3 Unraid Docker Hub
- 2.2.4 Unraid Docker 容器(Containers)
- 2.3 Unraid虚拟主机(Vms)
- 2.4 简捷方便的管理
- 3. Unraid Server安装
- 3.1. 系统需求-硬件要求
- 3.1.1 系统需求总述
- 3.1.2 引导设备-启动盘
- 3.1.3 网络附加存储-NAS
- 3.1.4 应用服务器(Docker Apps)
- 3.1.5 虚拟主机
- 3.2. Unraid官方认可的硬件设备
- 3.2.1 主板/处理器(CPU)
- 3.2.2 图形显示设备(GPU)
- 3.3. Unraid硬件兼容性列表
- 3.3.1. Unraid硬件报告
- 3.3.1.1 Unraid硬件报告说明
- 3.3.1.2 Unraid支持的主板清单1
- 3.3.1.3 Unraid支持主板清单2
- 3.3.1.4 Unraid支持主板清单3
- 3.3.1.5 Unraid PCI SATA控制器
- 3.3.1.6 Unraid其它硬件(网卡 内存 硬盘 ups等)
- 3.3.2 Unraid推荐的硬件
- 3.3.3 已知无法兼容Unraid硬件
- 3.3.4 Unraid其它硬件建议
- 3.3.1. Unraid硬件报告
- 3.4 Unraid快速安装及入门
- 3.1. 系统需求-硬件要求
- 4 Unraid Server其它设置
- 5. Unraid Server存储管理
- 5.1 Unraid分配存储设备
- 5.2 Unraid启动和停止阵列
- 5.3 Unraid阵列运算
- 5.4 Unraid缓存操作
- 5.5 Unraid文件系统管理
- 5.6 Unraid性能
- 5.7 Unraid共享管理
- 6 Unraid 应用程序Apps
- 7 Unraid Docker容器管理
- 8 Unraid 虚拟机(VMS)
- 9. Unraid WebGUI 操作教程
- 9.1 Unraid 仪表盘
- 9.2 Unraid WebGui主选卡操作
- 9.3 Unraid 共享
- 9.4 Unraid 用户管理
- 9.5 Unraid 缓存池操作
- 10 Unraid 安全
- 11 早期Unraid版本升级
- 12 Unraid更换U盘及注册码
- 13 Unraid故障排除
- 14 Unraid故障排除(旧版)
- 15 Unraid 常见问题(FAQ)
- 16 Unraid5旧版帮助
- 17 Unraid许可授权
Unraid故障排除
- 2020-02-23 12:35:28
- Unraid官网-tmtony翻译
- 21608
- 最后编辑:阿超 于 2020-02-29 15:39:14
- 分享链接
故障排除
本部分仍在建设中
仍然需要添加更多细节
大多数时候,Unraid系统运行时问题很少。本部分旨在帮助解决最常见的问题。
建议您遵循一些重要的一般准则,以帮助您进行可能需要的任何故障排除:
- 使用内置的帮助:Unraid GUI在GUI中的大多数字段中都内置了广泛的帮助。可以通过单击字段名称在单个字段级别进行访问,也可以通过单击
GUI右上方的图标在整个页面上打开/关闭。
- 启用通知:Unraid有一个通知系统,可用于使您了解Unraid系统的运行状况。可以启用它,并在“设置”->“用户首选项”->“通知设置”下调整您收到的通知级别。由于Unraid系统通常可以在很长一段时间内正常运行而无需用户监督,因此,当问题首次出现时,应及时通知您,这很重要,好像它们可能会变得更严重一样。
- 主动修复任何报告的问题:
- 在论坛中寻求帮助:Unraid拥有活跃的用户社区,并且活跃于Unraid论坛中的知识渊博的用户也很多。任何时候遇到问题并且不确定如何进行操作时,最好在论坛中提问。没有比立即尝试使用您不了解的过程来解决问题更糟糕的事情了,因此使最初很容易解决的问题变成了更严重的问题。
- 捕获诊断信息:如果您想在论坛中提出有关所遇到问题的问题,经常会要求您提供系统诊断文件。您需要这样做,在重新启动之前,以便重新启动之前日志显示出错(因为一旦重新启动,它就会丢失)!
捕获诊断信息
遇到任何类型的问题时,始终建议您尝试捕获尽可能多的信息,以帮助查明原因。如果您想在论坛中提问,通常会要求提供此类信息,因为这将加快获取有意义且准确的反馈的过程。
系统诊断
Unraid在“ 工具”->“诊断”下有一个GUI选项,可捕获有关系统状态的大量信息,这些信息在尝试诊断任何问题时可能会有所帮助。使用此工具将导致生成一个zip文件,该文件可以下载,然后附加到论坛帖子中。如果由于某种原因无法访问GUI,则使用Linux级别的diagnostics命令将生成相同的信息,并将生成的zip文件放入闪存驱动器上的logs文件夹中。重新启动之前,应尽可能捕获诊断信息,以使设备显示出导致问题发生的原因。在Unraid论坛中寻求问题帮助时,可以将生成的zip文件附加到论坛帖子中。
这些系统诊断信息包括配置信息,状态信息和关键系统日志。从GUI创建诊断时,将列出将包含的信息的详细信息。有一个选项(默认设置)说,诊断应该匿名,以尝试避免包含任何可能被视为敏感的信息。诊断程序中的所有文件都是文本文件,因此用户可以自由检查它们以检查自己到底存在什么信息。
有关诊断匿名化的注意事项
已经指出,如果您在设置->移动设置下启用了移动程序日志记录,则诊断不会完全匿名化, 因为系统日志将提供正在运行的文件的详细信息。这是一个catch 22场景,因为当启用了移动器日志记录时,通常是要调查一个问题,因为它捕获了尽可能多的详细信息,因此尝试匿名化此类信息可能会适得其反。由于默认情况下不启用移动器日志记录,因此建议的做法是仅在调查为什么移动器未给出预期结果时才启用它,这可能是可以接受的吗?
持久日志
主系统日志是syslog文件,当您单击Unraid GUI 右上角的图标时,将显示此文件的内容。请注意,在论坛上发帖时,提取的syslog片段很少有帮助,因为它们不会显示导致问题发生的原因。
通常,日志仅写入RAM,因此无法在重新引导系统的过程中幸免。如果您正在调查系统崩溃,那么只要您正在运行Unraid 6.7.2,现在就内置了syslog服务器支持
- 转到设置->网络服务-> Syslog服务器
- 镜像到Flash:这是最简单的设置。您从下拉框中选择“是”,然后单击“应用”按钮,系统日志将镜像到闪存驱动器的日志文件夹/目录,并在重新启动时附加到该日志。这种方法有一个主要的缺点。如果您要进行故障排除的条件需要几天甚至几周的时间才能发生,则可能会对闪存驱动器进行大量写入。有些人不愿意以这种方式使用闪存驱动器,因为这可能会缩短闪存驱动器的寿命。
- 远程系统日志服务器:当网络上有另一台计算机充当系统日志服务器时,将使用此服务器。这可以是另一台Unraid服务器。您还可以使用几乎任何其他计算机。通过搜索syslog服务器<操作系统>,可以找到所需的软件。设置计算机/服务器后,请填写计算机/服务器名称或IP地址。(我更喜欢使用IP地址,因为它永远不会造成任何混淆。)单击“应用”按钮,系统日志将镜像到另一台计算机。
- 本地Syslog服务器:将其设置为Enabled可以将此Unraid服务器设置为网络syslog服务器。启用此功能后,将提供一些其他选项。内置的帮助为/ n适当的设置提供指导。
- 本地syslog文件夹:这将是您服务器上的共享,但请谨慎选择。理想情况下,它将是“仅缓存”或“首选缓存”共享。由于将新行连续写入系统日志,这将最大程度地减少磁盘旋转。在这里,使用缓存优先共享,缓存SSD驱动器将是理想的选择。系统日志将位于该文件夹/共享的根目录中。)
- 本地系统日志轮换:通过这些设置,您可以控制系统日志允许使用多少空间。
- 本地系统日志最大文件大小:
- 本地系统日志文件数:
- 使用一些技巧,我们可以将有问题的Unraid服务器用作本地syslog服务器。
笔记:
- 标准系统诊断包括系统日志的RAM副本,因此无需单独提供此副本。您将需要这样做以提供系统日志服务器捕捉到的日志,这些都不是在标准系统诊断包括在内。
Docker容器
标准系统诊断程序包含的内容不足以帮助诊断特定Docker容器的问题。
需要更多细节
虚拟机
标准系统诊断程序包含的内容不足以帮助诊断特定VM的问题。
需要更多细节
开机问题
准备闪存驱动器
开机程序
在大多数情况下,Unraid引导过程可以无缝运行,并且用户不需要了解所涉及的各个阶段。但是,当出现问题时,了解引导过程可以成功进行的程度会很有用,因为这将有助于了解要采取的补救措施。
解决启动问题通常将需要本地连接的Monitor + Keyboard或IPMI连接(如果主板支持),以实现等效功能。然后,可以使用它来设置任何必需的BIOS字符串并监视引导过程。
Unraid的启动过程分为多个阶段
- BIOS引导:这是主板BIOS识别Unraid可引导闪存驱动器存在的阶段
- 将Unraid闪存驱动器设置为默认启动设备的方式取决于BIOS,因此您可能需要查阅主板的《用户手册》,以确定执行此操作的正确方法。
- Unraid闪存驱动器支持旧版BiOS的传统模式(有时也称为CSM模式)引导,而较新版本的UEFI支持引导。许多最新的BIOS支持两种模式。
- 如果要使用UEFI引导模式,则闪存驱动器上的EFI文件夹不得包含结尾波浪号(〜)字符。
- Syslinux加载程序:
- 引导菜单上显示的条目由闪存驱动器上的syslinux / syslinux.cfg文件指定。尽管从理论上讲该文件可以作为文本文件进行手动编辑,但建议通过GUI来完成,方法是单击“ 主”选项卡上的闪存驱动器,然后转到“ Syslinux配置”部分。
- Memtest86 +选项仅在以旧版模式启动时才有效。如果以UEFI模式启动,通常只会导致重新启动。如果要使用可以在UEFI引导模式下运行的版本,则需要从www.memtest.org或www.memtest86.com自己下载该版本。
- 如果用户未选择特定选项,则在超时时间后将使用默认选项。如果Unraid在无头模式下运行,则将运行该选项。
- Linux核心:这是syslinux引导加载程序从BIOS接管并开始加载syslinux.cfg文件中指定的文件的阶段。
- 这是从闪存驱动器加载核心Linux系统并将其解压缩到RAM中的时候。
- 控制台上将显示有关各种bz *类型正在加载到RAM中的消息。
- 如果在加载这些文件时显示任何错误消息,则通常表明闪存驱动器有问题。
- 在Linux启动并检测硬件环境时,将显示消息。
- 闪存相关服务:在此阶段,闪存驱动器已安装在/ boot上,因此该过程可以继续
- 如果闪存安装失败,仍然可以显示登录提示。但是,这并不一定意味着整个引导过程都正确完成。
- 如果引导过程的这一阶段尚未完成,则典型症状是未启动webGUI和网络
/dev/loop0 9344 9344 0 100% /lib/modules
/dev/loop1 7424 7424 0 100% /lib/firmware- 现在,上述安装点上提供了其他驱动程序和固件。
- 配置信息从闪存驱动器读入RAM。
- 标准Linux服务已启动。例如网络和(如果启用)WireGuard VPN。
- 外挂程式:
- 如果用户已安装插件,则通常会在此阶段加载它们。
- 如果从Unraid Boot菜单中选择了“安全启动”选项之一,则将抑制插件的加载。
- Web GUI:
- Unraid Web GUI已启动。
- webGUI实际上是通过闪存驱动器上config / go文件中的条目完成的,因此用户提供的命令也可以在启动webGUI之前或之后立即从那里运行。
- 数组如果用户将阵列设置为自动安装,则将开始以下操作。如果未设置阵列自动启动,则当用户选择启动阵列时会发生这种情况。
- 驱动器已安装
- 文件共享服务
- Docker容器
- 虚拟机
到此阶段,Unraid服务器将完全运行。
引导失败
以下是可以尝试尝试确定引导失败原因的一些操作:
- 如果可能的话,请优先使用USB2端口而不是USB3端口,因为它们似乎更易于引导。
- 检查Unraid服务器上的BIOS仍然将闪存驱动器设置为引导设备。毫无明显的原因可以重置它。
- 在Windows 10 PC或Mac上,对闪存驱动器进行检查
- 这将确定闪存驱动器在物理上或逻辑上是否存在问题
- 如果还没有,请确保您拥有plash驱动器的config文件夹的副本,因为它包含您当前的所有配置信息。
- 从Limetech下载该发行版的zip版本,并提取所有bz *类型的文件,以覆盖闪存驱动器上的文件
- 这将确定这些文件是否由于某种原因未正确写入或已损坏。
- 使用Unraid的干净副本重写闪存驱动器,然后仅将密钥文件从备份复制到config文件夹
- 这可以确定闪存驱动器本身是否正常
- 将config文件夹的其余内容复制到闪存驱动器
- 如果一切顺利,则可以备份并运行完好先前的配置。
- 如果失败,请尝试以安全模式启动。如果可行,则插件引起问题
- 如果无法使原始闪存驱动器启动,请尝试使用全新的闪存驱动器并清除Unraid的副本(使用默认配置)
- 这可以确定服务器硬件(mobo,cpu,ram,usb端口等)是否存在问题。
- 在新的闪存驱动器上安装全新的Unraid副本,然后从旧的副本复制config文件夹。
- 如果可行,则需要将许可证转移到该新的闪存驱动器。
忘记root密码
有时,用户会通过Unraid WebGUI或控制台丢失用于管理Unraid的密码。这可能是因为他们只是忘记了密码,但是闪存驱动器损坏也可能导致密码无法识别。
共享密码可以通过Unraid webGUI更改/重置。
要重置管理密码,请使用以下过程:
- 关闭服务器,然后将USB引导闪存设备插入PC或Mac
- 虽然有一个好主意,但对闪存驱动器进行检查并对其内容进行备份
- 删除这些文件:配置/密码配置/阴影配置/ smbpasswd
- 将闪存重新插入服务器,然后重新启动。
请注意,这会将包括“ root”用户在内的所有用户密码重置为空(空白)。
有一个替代过程可用于仅重置根密码(但更容易出错):
- 将USB驱动器插入另一台计算机
- 对以下文件添加编辑器(例如Notepad ++):/ boot / config / shadow
- 在第一行,您应该看到诸如以下内容:根目录:$&$&%* 1112233484847648DHD $%.: 15477:0:99999:7 :::
- 将该行更改为以下内容(基本上删除第一和第二分号之间的内容):根目录:15477:0:99999:7 :::
- 将闪存重新插入服务器,然后重新启动。
关机问题
本部分仍在建设中
崩溃问题
本部分仍在建设中
Windows连接问题
本部分仍在建设中
大多数用户都可以轻松连接到Unraid共享。话虽这么说,微软正在通过Windows Update不断调整网络安全模型,这可能会对某些用户造成问题。
如果遇到问题,则第一个呼叫端口应该是Unraid论坛线程中的 Windows问题。该线程很长,因此您可能希望从末尾开始。
这里要添加的常见问题和解决方案
名称解析
存储的凭证
多次登录
数据恢复
本部分仍在建设中
仍然需要添加更多细节
本部分是关于当Unraid报告一个或多个驱动器问题时恢复数据。
在保护数据安全时,需要牢记一些要点(
- 备份关键数据: Unraid可以保护您免受大多数类型的简单硬件故障(而不是灾难性故障)的影响。您应该始终备份任何您无法承受的重要数据。理想情况下,这些副本之一应位于异地或在云上,以保护自己免受意外情况的影响,例如火灾,盗窃,洪水等。
- 每个用户都必须自己确定自己认为关键的内容,并评估他们准备承担的风险级别。
- 诸如照片和文档之类的个人数据通常被认为是至关重要的。幸运的是,它们往往相对较小,因此易于备份。
- 媒体文件通常被认为是非关键文件,并且相对较大,因此用户可以确定这些文件不值得备份
- 无论大小如何,都无法替换的个人视频应归为重要类别
- 请记住,周围存在诸如勒索软件之类的东西,因此,如果您不幸遭受此类攻击,则应该至少有一份不能在线访问且已损坏的关键文件副本!
- 积极主动地解决Unraid检测到的所有问题。确保在“设置”->“通知”下启用了通知,以便在检测到问题后立即通知您。对于很多用户来说Unraid在操作发射后不管模式,使得他们不会主动检查问题,所以需要这样的提醒。
- 请求建议:
- Unraid论坛上有很多知识渊博的用户,如果您不确定要采取的最佳步骤是什么,可以帮助您指导需要做些什么来使数据恢复为标准。
- Unraid可以很好地保护您的数据免遭典型的硬件故障的侵害,但不能避免用户在发生故障后采取不适当的步骤来恢复其数据。
阵列丢失配置
如果您丢失了阵列配置并且没有闪存驱动器的当前备份,则驱动器上的数据仍将保持不变。
所有配置信息都存储在闪存驱动器的config文件夹中。特别是Unraid阵列配置存储在config / super.dat文件中。
- 请勿尝试使用可能具有错误驱动器分配的过时备份。
如果您知道哪些驱动器是奇偶校验驱动器,则只需重新分配驱动器即可。但是,如果您不知道哪些是奇偶校验驱动器,则必须格外小心,因为错误地将驱动器分配给真正的数据驱动器会导致丢失其内容。
当您不知道哪个是奇偶校验驱动器时,以下步骤可以使阵列恢复运行:
- 将所有驱动器分配为数据驱动器
- 启动阵列
- 所有真正的数据驱动器应显示为已安装,而奇偶校验驱动器应显示为unmountable。如果不是这种情况,并且太多的驱动器显示为无法安装,请停止并在论坛中寻求帮助,以详细说明发生的情况。
- 记下奇偶校验驱动器的序列号。
- 停止阵列
- 转到工具>>>新建配置。选择保留当前分配的选项(因为这样可以减少出错的机会)。单击是,我要执行此操作,然后单击应用。
- 返回“主要”选项卡,并更正奇偶校验驱动器的分配。仔细检查一下,您现在已将正确的驱动器分配为奇偶校验驱动器,因为将数据驱动器分配给奇偶校验将丢失其内容。您也可以在此阶段移动其他驱动器。
- 启动阵列,系统将根据当前分配开始构建奇偶校验。
您的所有用户共享都将重新出现(因为它们只是每个驱动器上顶级文件夹的汇总),但是具有默认设置,因此您可能需要重新应用所需的任何自定义设置。
现在,您可以进行任何其他合适的自定义,并添加通常使用的所有插件。
此时,强烈建议您单击“主要”选项卡上的闪存驱动器,然后选择用于下载闪存驱动器备份的选项。每当您进行重大更改时,始终最好这样做。
使用ddrescue从故障磁盘中恢复数据
在正常使用中,使用“ 更换磁盘”过程在“未检查”状态下恢复了已尾部/禁用的磁盘。
有时可能由于多种原因而发生这种情况,例如,奇偶校验无效时磁盘发生故障或两个奇偶校验磁盘发生故障,用户的磁盘故障且挂起扇区且无法使用奇偶校验来重建磁盘,这是正常的Unraid恢复过程不能使用。在这种情况下,您可以尝试使用ddrescue挽救尽可能多的数据。
要安装ddrescue,请安装Nerd Pack插件,然后转到Settings-> Nerd Pack并安装ddrescue。
您需要一个额外的磁盘(大小或大于故障磁盘),才能使用控制台/ SSH类型将旧磁盘克隆到其中:
ddrescue -f / dev / sdX / dev / sdY /boot/ddrescue.log
源磁盘和目标磁盘均无法安装,将X替换为源磁盘,将Y替换为目标磁盘,请始终对它们进行三重检查,如果将错误的磁盘用作目标磁盘,它将被覆盖并删除所有数据。
也可以将阵列磁盘用作目标磁盘,尽管只有在其大小与原始磁盘相同的情况下,但是为了保持奇偶校验,您只能克隆该分区,因此现有阵列磁盘必须是任何文件系统中已格式化的Unraid磁盘,仍然要保持奇偶校验,您需要使用md#设备,并且该阵列需要以维护模式启动,即,使用以下命令在复制期间不可访问:
ddrescue -f / dev / sdX1 / dev / md#/boot/ddrescue.log
将X替换为源磁盘(在源磁盘标识符中注释de 1),将#替换为目标磁盘号,建议先启用Turbo写入,否则将花费更长的时间。
第一遍的示例输出:
GNU ddrescue 1.22 ipos:926889 MB,未修剪:1695 kB,当前速率:95092 kB / s opos:926889 MB,未刮擦:0 B,平均速率:79236 kB / s 未尝试:1074 GB,坏扇区:0 B,错误率:0 B / s 获救:925804 MB,不良区域:0,运行时间:3h 14m 44s pct获救:46.28%,读取错误:54,剩余时间:3h 18m 自上次成功读取以来的时间:0s 复制未尝试的块...通过1(向前)
复制完所有好块之后,ddrescue将重试坏块,向前和向后,这最后一部分可能要花一些时间,具体取决于磁盘的坏程度,例如:
GNU ddrescue 1.22 ipos:17878 MB,未修剪:0 B,当前速率:0 B / s opos:17878 MB,未刮擦:362496 B,平均速率:74898 kB / s 未尝试:0 B,坏扇区:93696 B,错误率:102 B / s 获救:2000 GB,不良区域:101,运行时间:7h 25m 8s pct获救:99.99%,读取错误:260,剩余时间:25m 自上次成功读取以来的时间:10秒 报废失败的区块...(向前)
克隆完成后,您可以手动安装目标磁盘,也可以使用例如UD插件安装(如果克隆的磁盘不可卸载,请运行相应的文件系统修复工具,即使已安装确定也可以运行文件系统检查,这也是个好主意) ),然后将恢复的数据复制到阵列中,某些文件可能会损坏,如果您具有校验和或正在使用BTRFS,则可以轻松找出哪些文件(如果未在下面看到)。
如果您没有文件的校验和(或使用btrfs),则仍然可以通过一种方法检查受影响的文件:
创建一个临时文本文件,其文本字符串不包含在数据中,例如:
printf“ unRAID”>〜/ fill.txt
然后用该字符串填充目标磁盘上的坏块:
ddrescue -f --fill =-〜/ fill.txt / dev / sdY /boot/ddrescue.log
用克隆的磁盘(不是原始磁盘)替换Y,然后使用现有的ddrescue映射文件。
最后,手动或例如使用UD插件安装磁盘并搜索该字符串:
查找/ mnt / path / to / disk -type f -exec grep -l“ unRAID”'{}'';'
用正确的安装点替换/ path / to / disk,将输出所有包含字符串“ unRAID”的文件,而这些文件都是损坏的文件,这将需要一些时间,因为将扫描磁盘上的所有文件,仅显示输出最后,如果没有输出,则坏扇区位于没有任何文件的区域。
Docker
本部分仍在建设中
仍然需要添加更多细节
Docker映像已满
Unraid期望将Docker容器配置为仅将容器的二进制文件保存在docker.img文件中。然后应该将容器内所有写入变量数据的位置映射到docher.img文件外部的位置。
除了要求最苛刻的用户外,默认大小为20GB足以满足所有用户的需求,因此,如果您发现docker.img文件空间不足,则肯定听起来好像您至少配置了一个容器,所以它在内部写入泊坞窗映像,而不是存储在映像外部。
常见的错误是:
- 省略路径映射的前导/在容器端,因此它是相对的而不是绝对的
- 由于Linux路径名区分大小写,因此路径映射两侧的大小写不匹配。
如果无法发现错误,则可以尝试:
- 转到docker选项卡,然后单击Container size按钮。通常这会突出问题docker容器,因此您现在知道在哪里看。
如果这还不足以确定罪魁祸首,则:
- 确保所有容器均已停止并且未设置为自动启动
- 停止docker服务
- 删除当前泊坞窗映像并设置更合理的大小(例如20G)
- 启动docker服务
- 使用应用程序>>>以前的应用程序重新安装容器(所有设置不变)。
- 转到docker选项卡并单击Container size按钮
- 启用一个容器,使其运行一会儿,然后再次按“容器大小”按钮以查看该特定容器在运行时是否正在占用空间。
- 重复上述步骤,直到找到恶意容器为止