NAS不完全指南

高卢鸡

ArthurFyc 发表于 2024-10-20 09:57
前阵子把绿联的机器刷了个 unraid，自己用着一直挺好，但是昨天想给朋友共享文件遇到了一些难题。
本身我有 ...

下载、内网网络访问主要用什么系统？可以在那个系统下开ftp。
不建议在宿主系统里服务，有安全风险与增加出问题的风险

—— 来自 鹅球 v3.1.88.3

Lazia

ArthurFyc 发表于 2024-10-20 09:57
前阵子把绿联的机器刷了个 unraid，自己用着一直挺好，但是昨天想给朋友共享文件遇到了一些难题。
本身我有 ...

公网开smb有点勇。。。换webdav或者sftp吧。

愤怒的栗子

借楼问问最便宜的局域网内NAS方案是啥？单盘位就够用
我的路由器能挂硬盘，但是读取大文件时间长点就会掉盘

simon2137

愤怒的栗子 发表于 2024-10-20 16:03
借楼问问最便宜的局域网内NAS方案是啥？单盘位就够用
我的路由器能挂硬盘，但是读取大文件时间长点就会掉盘 ...

pdd上买个n1刷omv或者casaos，一般卖家能代刷。

—— 来自 HUAWEI BRA-AL00, Android 12上的 S1Next-鹅版 v2.5.2-play

tuorew

squallx 发表于 2024-10-19 23:38
看了一圈成品极空间Z4PRO盘符合需求 就是这8G版本如果插电视播4K够不够？ 有必要上16G版吗 docker一些音影 ...

docker一个大概占用100-500mb内存，用得不多8g应该是够用的。我现在是8+4组了个12g的，因为还开了一个1g的虚拟机软路由所以有些不太够用

Kaiyan

ArthurFyc 发表于 2024-10-20 09:57
前阵子把绿联的机器刷了个 unraid，自己用着一直挺好，但是昨天想给朋友共享文件遇到了一些难题。
本身我有 ...

我也是unraid，直接docker装个file browser不行么

maritimus

为什么大家都爱用docker？自己apt/yum/pacman也不会出啥问题其实，都是系统打包好的

Lazia

maritimus 发表于 2024-10-20 22:16
为什么大家都爱用docker？自己apt/yum/pacman也不会出啥问题其实，都是系统打包好的 ...

和绿色软件差不多意思，而且配置和数据方便集中管理，备份的时候打个包就全带走了，再部署只需要重下镜像。

password

maritimus 发表于 2024-10-20 22:16
为什么大家都爱用docker？自己apt/yum/pacman也不会出啥问题其实，都是系统打包好的 ...

流行的成品NAS系统很多不让你这么干的，群晖DSM就是典型，本身不带apt/yum/pacman这样的包管理器。

而白群和黑群加起来DSM大概是国内最流行的NAS系统了。

AraTurambar

maritimus 发表于 2024-10-20 22:16
为什么大家都爱用docker？自己apt/yum/pacman也不会出啥问题其实，都是系统打包好的 ...

Linux桌面安全模型太简陋了，有了flatpak和wayland之后才勉强能看一点。

但也就是一点，远不如直接扔进VM或者CT里面好，大家爱用这类东西也很好理解。

ArthurFyc

Lazia 发表于 2024-10-20 10:44
公网开smb有点勇。。。换webdav或者sftp吧。

smb 主要是为了远程备份时间机器。今天才知道 filebrowser 这个东西，基本解决问题了。后面研究一下怎么用 wireguard 连 smb

—— 来自 鹅球 v3.3.92

lionheart

这两天折腾服务分离，重新梳理了媒体库工具链，记录一下。

下载
pt站+bt客户端。市面上可能有通过网盘或者其他方式流传的媒体资源，没有接触过。
bt客户端使用transmission，docker部署，以transmission web control作为前端。

存储
存储没啥特别的，加上媒体库文件结构+保种两项需求后，在具体的操作上通过小技巧可以更加方便一些。
transmission web control可以通过前端对下载文件进行移动归类，一般按照movie、tv、bdmv之类的做些汇总整理也就够用了；偶尔有些不大符合媒体库要求的比如单独文件之类，写了个小脚本对它们作硬链接。

刮削
整理完文件结构，在网络畅通的情况下，媒体库本身应该可以很好的完成刮削。
关于动作片，pokies老师20年前后那篇很好的文章中提到的工具经过这些年发展变成付费的了，目前免费同类工具用起来比较好的是javsp。

媒体库
有多个屏幕播放媒体文件需求的情况下，总是需要一个媒体库服务端。我使用的是jellyfin，docker部署。
jellyfin和存储不在同一个物理节点下，不过它使用的docker-compose文件以及媒体文件都是通过fstab挂载nfs共享的。为不同机器上docker-compose文件内容统一，参照存储机器的文件结构，jellyfin的宿主机上做了些类似/volume1/video到/mnt/video的软链接。
另外考虑到断电恢复的文件共享服务重启时间，jellyfin宿主机的自动启动时间需要配置延后好几分钟才行。

客户端
jellyfin的客户端五花八门，就个人经验，40寸以下屏幕直接使用web ui就够了。
如果以安卓电视作为播放器，受限于普遍使用1080p的ui分辨率以及HDR杜比视界音效之类高级特性支持不足，客户端只要保证能正常播放就行，也追求不了左上角的视频特性显示。
客户端软件方面选择有jellyfin tv、kodi+jellyfin for kodi、kodi+jellycon+支持自定义widget的皮肤，主要差别也就在海报墙形式、bdmv转发的兼容性和盒子性能要求上，配合kodi的profile，三个方案一起上也不是什么麻烦事。
kodi皮肤这块，embuary已经两年多没更新了，现在比较类似的是jurialmunkey的arctic系列。


总体来说，开源方案比较依赖作者，之前看到jellyfin for kodi和jellycon的作者说维护两个插件太忙，本来想基于embuary做些延展开发，实在没时间。这几年nas和播放器厂家入局的不少，基于开源方案做了不少定制化开发和私有化服务部署，媒体库服务和客户端也是不少厂家的着力点，整体使用体验应该是比开源方案有所改进的，希望后续也能做一些反哺工作，加强一下开源工具链条。

lionheart

风怒zsbd