Unraid 小马过河避险手册（二）谁挟持了我的文件

朋友被安利了Unraid，几天后问他才知道，他跪了，倒在了奔向成功的小道上。这个情况其实让我有点震惊，最近看了社区一些文章，后面很多朋友似乎也被一些拦路虎给折磨的够呛，想了想就这里写一些壁坑点吧，给有需要的朋友了解一下。网上已经有很多unraid的基础教程了，很多还非常详细，这些内容会会直接跳过。另外这个是给比较小白的网友看的，很多描述为了便于理解会不那么严谨，主要是给大家闭坑，并希望这些解决思路能给大家一些启发。

这一篇，是我在使用中一些场景下发生的问题，后续我研究了一下，一些过程和心得跟大家分享一下。这一篇有用的信息很少，但是个人觉得其中一些思路是非常有启发性的，所以拿出来跟大家分享。百度google是解决问题的好办法，但是更重要的是自己的逻辑思考能力，这样会便于我们理解为什么。毕竟，单纯的硬记，真的是学习中非常大的硬骨头，对于效率来说，副作用太大了。

错误范例：Emby里面，把第二个背景图移动到第一个，提示错误，不成功。

更换背景图顺序

场景解释：原数据是用jellyfin刮削的，后续再emby内下载了新的背景图，并想更换默认背景，提示失败。

跟第一帖一样，先上截图，这是jellyfin刮削后，电影文件夹目录的信息：

jellyfin刮削后电影文件夹

emby中下载两个背景图后，文件夹情况是这样子的：

我们来看，有啥不同，fanart1/2是新下载的背景图，报错图片，其实就是修改fanart和fanart1，将两个文件互换，造成无法操作必然是emby无法对两个文件进行写操作。我们尝试，fanart1、fanart2文件是可以正常更换顺序的，问题就出在fanart文件上了，那么fanart和fanart1有什么不同呢？ #poster文件是因为我在emby里面更换过了，这个文件已经是emby写入的，所以会和fanart不一样，我们主要看fanart和fanart1/2。

图片中很明显他们不同就在权限，拥有者，两个列值不一样。而jellyfin emby两个软件生成的文件，又和直接拷贝进unraid的电影及字幕文件权限、拥有者不同。

• fanart.jpg rw--r--r-- 1000
  

• fanart1.jpg rw-rw-rw- 99

• mkv&sub rw-rw-rw- 1000
  

这里我们思考一下，想想上学时候学到的基础编程，顺便翻翻window文件属性看看。

windows文件夹权限属性

根据常识推断，首先有两个结论 ：

• 不同用户对文件的权限明显是不同的，emby没有办法操作，应该是没有权限

• 每个docker操作时候使用的用户名和权限不同
  

那么我们继续，来看看系统账户设定，共享时候用的是哪个用户，以及jellyfin-emby两个docker设置上有哪些不同。

账户相关的一键三图：

结论和实际情况：我们使用的admin账户来拷贝电影文件夹

接下来看docker设置： #一些朋友会在这里看到我docker设置和大家的会有些不同，会尽量说明；上面是emby，下面是jellyfin的

emby的

我们来先来看docker设置上的差别，主要是两个地方：

• PUID不同，emby 99 vs jellyfin 1000

• emby多了 UMASK=000 这个参数

回头看，他们写入文件的区别是：

• fanart.jpg rw--r--r-- 1000
  

• fanart1.jpg rw-rw-rw- 99

1.我们不看P，UID？应该是user ID吧？翻到早先的图片，对应关系很明显，emby写入文件是99，jellyfin是1000，对上了。

2.接下来就是UMASK: 000 这个玩意了，那么他是不是造成多了w的原因呢？答案是，对的，就是这个原因。我们来试一下。我们给jellyfin docker加上这个参数：

jellyfin加入umask参数

然后我们在jellyfin中删除海报，背景图，重新下载，再看文件夹文件情况：

fanart.jpg也变成rw-rw-rw-了！这证明我们的判定是对的。

接下来我们更改emby的GUID=1000来实验下：我们进入emby，删除emby添加的两个背景，重新添加，然后尝试更改默认背景：

成功了！

成功了！！！

我们来看文件夹：

清一色的1000和rw-rw-rw-。#nfo文件因为我们一直没有对他重新做过操作，他属性一直是jellyfin第一次生成时候的状态。

下面我们要开始进阶了，我们需要思考几个问题：

1. 建立docker时候，我们如何确定PUID该输入多少？

2. rw-rw-rw-的结构和rw-r--r--是否非常相似，这种相似和不同在哪里？

3. UMASK 英文非常好理解，面罩，罩子，而000三个数字和rw-rw-rw-明显的三段结构非常引人遐想，他们的联系在哪里？

让我们一个个解释和尝试：

ID：让我们点击这个图标，他的图形明显表示他是个终端，命令行输入器之类的玩意。

让我们试试输入id看看：#程序代码属于逻辑性语言，可以说是在非常有逻辑性的说话，这种所谓命令行形式的程序操作逻辑性表现非常明显，所以我们要查id，就直接试id这个单词，八成没错。

使用我们学习过的计算机基础知识，来做简单的逻辑分析：root@tower： 我们登录网页是用的root账户，tower是我们的unraid名字，id我们没有输入参数，那么我们看到的应该就是现在终端的使用者root的id信息。我们试试把admin用户做参数加入：

内容如下：uid=1000(admin) gid=100(users) groups=100(users)

非常明显，GID，UID，明确对应了docker里面的PUID，PGID信息。

那么如果我们想省事，就把docker，samb，ftp用户都用admin，PUID=1000&PGID=100，那么日常工作文件的所有者就是同一个人了，会省却不少麻烦。

对了，在思考一下，那么docker默认的PUID=99又是那个神秘人呢？那么试试：#同上面说的逻辑性语言，我们要了解99用户，就直接输入99，编程应该是灵活的，至少用户名用户id在查询时候应该是同样有效的，不然程序就太死板了太老旧了。反正先试试再说。

nobody

额，神秘用户啊，这个名字就很奇特，没有人。想了解的可以自己再去查询了，linux的用户和权限体系其实很好理解，这里就不多讲了。文章的主要目的是引导大家如何入手分析一些问题，提出一种思路罢了。

rw-rw-rw-：这里大家应该能体会到学英文真的非常有用，rw，这he mothered明显就是read，write的缩写，读，写；r--就变成了只可以读，这个非常合乎逻辑。那么问题就是，问什么有三段呢？

继续回到计算机基础知识，三段式设计，肯定是针对三种对象啊，电脑用户看成人群，那么三，如何分？

我们在百度前先来拼凑一下知识，联系一下逻辑推理：

• 首先系统有所谓管理员账户，win的administrator，linux的root；然后文件刚才说有拥有者，这就占两个了，那么第三个呢？对了，现在的系统都叫什么来着？多用户系统，unraid可以继续添加帐号，比如你爱人的孩子的，然后给予他们不同文件夹的分享权限，这个是nas基本的需求。那么你爱人和孩子对比管理员，拥有者，有什么共通性呢：他们都是非拥有者，非管理员，他们就是普通的其他用户。那么三类就分出来了。

• 继续追问一下，用户系统其实更复杂，他还有用户组，GID ，group ID，那么情况就更复杂了。管理员组应该是有创灭世权限的；拥有者归属的用户组，权限是否是继承性的，就像父母的扶养义务会继承给爷爷奶奶，叔叔伯伯，因为他们都是直系亲戚组的；然后其他组，比如那个99 nobody组。

• so，说说结论，管理员应该是不需要命名权限的，管理员组应该也一样，那么三组对象里面就没有他。拥有者本人是一个对象，这个就是父母一样是特殊的，应该是单独申明权限的，然后就是拥有者所在的组，在然后就是所有其他用户，不管是用用户id，还是组id，他们都有个标签，就是不相关。

然后就百度吧，你会发现结论跟推断很相似。这里我就不列举百度结果了。

然后说umask，这个我默认大家百度过chmod 777这回事了。那么000很明显，就是对应777三个数字的。mask，明显的是盖住777的，其实就等于777每一位，单独减对应的000。数字越大，文件写入后剩余权限就越小了。至于文件夹默认755，文件666之类的，大家懂含义后，自己观察观察就能发现了，一些docker也会写明自己默认生成文件的权限信息，明白理论后，实践起来就会非常有条理，非常容易上手了。