硬解，从入门到放弃
说多了都是泪，其实也花了很多时间研究jellyfin硬解的问题，在lxc中能识别到核显，但无法使用。使用docker的方式能正常解码，但cpu占用是爬升。想了很久，平时大部分的视频，都是直接播放，不涉及转码，要硬解有何用？
最终，在折腾中放弃了硬解方案。
从jellyfin到emby
包括plex，三个都装了一下。五年以前，最早接触的就是plex。对比了一下，看重emby的随机播放。jellyfin也有。反正就是腻了要换一下。
确定使用LXC容器，但不想套docker了，确实有点小问题。一路安装成功，最终发现只读不可写，这又是一波猛操作猛折腾。多年以前我写过文章，提到了文件挂载问题，有网友就问写权限怎么办？那时我不关心写，现在我希望整体管理。挖坑又开始了。
LXC，映射权限入门到放弃
不管是硬解、docker、现在的只读不可写，都和LXC的映射机制有关。
特权容器，主机对LXC都是一样的，这样有风险。所以默认非特权，主机的用户和用户组从0开始，对应LXC容器里的用户和用户组从100000开始。
好家伙，你干破了LXC安全防线，很快你发现无权访问宿主机真实内容。你以为是root的ID，其实你在宿主机那的ID是100000，没招了吧？但这给我们造成了困扰。
在硬解时代，就是要把特定的用户和组ID映射到主机上
在非特权LXC运行Docker时代，也是要映射相应在用户和组。在容器添加普通用户，通过加入sudo组执行docker。当然，添加的普通用户是要映射到宿主机上的。
在emby读写授权时代，也是涉及到映射问题。如果宿主机用户及组ID为1000，在LXC容器中创建了用户及组ID为1000，把emby的用户加入到组1000中。再加上映射，这样，宿主和容器中的用户1000和emby的966都对应了，按理可以读写？
不行的，很快你发现，主机中的996并不是emby，你在LXC中授权了emby加入用户组1000，宿主机上发现没有emby这个对象。或者，你可以尝试授权996加入组1000。
你以为，开启特权模式就牛逼了？其实和上面的情况是一样吧，只不过一个全部对应，一个手工对应。
好累啊，搞不赢了
反正，太累了，不如换个简单的方法吧。既然容器996对应主机上的100996。那直接在主机授权吧
chown -R 100996.100996 /mnt/st2/
find /mnt/st2/ -type d -exec chmod 755 {} \;
find /mnt/st2/ -type f -exec chmod 664 {} \;
然后，删除动作丝滑流畅。
得，创建smb共享，直接使用emby用户就好了，反正宿主机里root万能
但是，如果别人攻破了你的容器，这些文件有危险噢
映射的资料
# uid map: from uid 0 map 1005 uids (in the ct) to the range starting 100000 (on the host), so 0..1004 (ct) → 100000..101004 (host) lxc.idmap = u 0 100000 1005 lxc.idmap = g 0 100000 1005 # we map 1 uid starting from uid 1005 onto 1005, so 1005 → 1005 lxc.idmap = u 1005 1005 1 lxc.idmap = g 1005 1005 1 # we map the rest of 65535 from 1006 upto 101006, so 1006..65535 → 101006..165535 lxc.idmap = u 1006 101006 64530 lxc.idmap = g 1006 101006 64530
u是用户，g是用户组。0是宿主机，100000是容器。最后一个是增加的id数
如果宿主机用户1000对应容器的1005，只有一个端口。那么就是：
lxc.idmap = u 1000 1005 1
别忘了在 /etc/subgid、 /etc/subuid 两个文件中都加入：
root:1005:1
期待您的评论或捐赠，这是最好的鼓励和支持！
