@mokeyjay @cnrting @EridanusSora @biu7 @efaun @mineralsalt @v2ka

关于很多人反应的界面简陋，完成度低的问题，我统一来回复下。


首先，这个软件的定位，基于国内的互联网环境，想要做一个面向大众的网盘、图床服务，不是大公司是不可能的，法规就通不过。所以这个软件的定位很简单：自己或亲近的少数几个人使用的，Self-hosting 应用。

由于这个定位的关系，多用户分不同的空间，我觉得意义也不是很大了。这个软件可以支持多个用户名，密码，但是看到的是同一个东西。不同密码的存在只是为了保护自己的密码不告诉别人。（有时候密码都用的一样的不方便告诉别人）

然后，我想自己做一个来用最大的原因是，市面上很多的开源网盘、是不支持视频略缩图（或者配置不好弄），和不支持大文件上传（超过 200M ）。有这两个功能，就能满足我上传文件 ——》 分享文件 外链给别人的需求了。

界面简陋这一方面，个人觉得是还行，主要是上传后拿到文件公网链接就行了。另外附带了文件预览的功能。

关于功能少，我做的时候是尽量想怎么能减少功能，比如文件列表，需不需要多选，批量删除？文件视图 需不需要有“详细列表”形式、“大略缩图”形式、“小略缩图”形式？需不需要有文件夹功能？我个人觉得是可以有，但是收益产出比不大，因为 40GB 的云服务器，注定当不了在线 NAS 使用。不过音频在线预览、pdf 、纯文本在线预览倒是可以支持一下，也简单。可能 docker-compose 部署，让人看着觉得很复杂，其实代码前端就 两个 js 文件，后端 express 就一个 js 文件和几个小的 util js 文件，结构非常简单，不至于让我写着写着自己都改不了了。

搜索功能：文件列表接口会一次返回所有的文件（从 redis 缓存中读取），所以 ctrl + F 页面内查找文件名 可以当作是搜索功能。

关于不值，这个我不做评论。

关于不如一个毕业设计的，我想可以做到 分片上传、断点续传、秒传功能，而且支持分片上传显示整个文件上传进度，支持 OSS 对象存储 和 CDN （简单方便设置回源规则），支持视频略缩图，支持类似手机相册的全屏滑动预览，支持视频满屏播放（非全屏状态）的。欢迎提供优秀的毕业设计作品供借鉴学习。

最后，如果您恰好需要这么一个界面简洁，功能符合要求的文件上传分享系统。欢迎与我联系。

@o00o 如果指的是 文件同步、webdav 那些功能的话，应该是用不上，因为考虑到网上买的轻量云这样的服务器 ，存储容量有限 40GB ，8M 的带宽也只够自己和朋友用用了，最好是只当作一个文件分享的工具来用。

当然后面考虑继续添加有用的功能。:)

@yukiww233 感谢回复。 开源方案有时配置比较麻烦，比如 NextCloud 不能视频略缩图、不能上传超过 200M 的文件。网上找了很久也没有配置成功
（我记得那时修改了 nextcloud 的 nginx.conf 文件，post size 设置了更大的，还是没有起作用。）
视频略缩图是要安装一个 ffmpeg ，但安装成功了也没起效。
主要是这个简单是自己可控的。

demo 网站 8M 水管 ，瞬间顶不住了

jquery 和 vue 这些不是可以一块用嘛，
不过一般也就用个 $.ajax ，返回也都是 promise 的。

@guog
@ijk0 哦，是这个意思，还以为是拼音缩写或者楼主的直译 owner of post

@hand515 话说这个新加的 OP 是啥，还挺好看的，就是不知道什么意思

非针对哈，只有我觉的楼主很有钓鱼嫌疑嘛，呵呵。
楼主挺厉害，故意把 数据绑定 写成 响应式，
故意说不懂前端，TypeScript 也用上了，nodejs 写后端也用过了。async await promise 也用的很溜了。

我想楼主可能已经是用原生 js 自己写组件的前端大牛了吧。

不专业，说说自己的个人经验。跑步弄黑过大脚指甲、摩伤过大腿内侧、摩出血过奶头（男的），这些都慢慢自己好了，学会了必须剪脚趾甲跑步而且穿专业的跑步袜，必须要穿专用的跑步短裤，奶头摩出血倒是没出现过了。

膝盖受伤也遇到过，经过长时间停跑后（应该有半年），觉的又能跑一跑了。膝盖有时候不适，确实是跑起来反而好了（但是如果跑步根本坚持不了了绝对不要硬撑）。有一个建议就是在自己状态没达到一个很好的时候，不要盲目的想着一定要跟上前面人，这个有可能会受伤。

目前找到一个 便利 和 安全 之间相对折中的方法， 就是：所有的服务器都用同一个 ssh 私钥。ssh 私钥设置 passphrase ，并且 passphrase 保存到 macOS 的 keychain （使用 ssh-add -K keyfile ）

@Osk
@dddd1919
@shangyu7
@pixelcn
@ziseyinzi
@ysn2233 发现原因了，又是自己的粗心大意浪费了大量的时间。

应该是 ~/.ssh 设置为权限 700
~/.ssh/authorized_keys 设置为 600

我设置反了！ 想当然 ~/.ssh/authorized_keys 是文件需要 执行权限， ~/.ssh 是文件夹 只要 读写权限就行了。

后面搜到才发现弄反了。

server A （成功）是因为 ， 没有手动去改 chomd 权限， ~/.ssh/authorized_keys 默认是 644 的权限。


经常会这样自己搞死自己，浪费大量的时间、熬夜，因为那一块是确认过了的，认为那里肯定是没有问题的，就没想到再去确认一次。大家有没有同样的经历？或者如果规避自己的低级错误导致卡壳的情况？

混进一个用 java 的公司，直接被逼着用，一下就学会了

@starsky007 一直这么写的，这还有一个说法的啊

抱歉，之前有事情现在才更新。

这两台服务器 是这样的，都是用 docker 起的 ubuntu 镜像容器，而且镜像是一模一样的。开放出了 ssh 端口。

这是两台服务器的 openSSH 版本 ssh -V

服务器 A 和 服务器 B 的结果都是一样的：
OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g 1 Mar 2016

本身操作用的 macbook pro 的 ssh 版本：
OpenSSH_7.4p1, LibreSSL 2.5.0

/etc/ssh/sshd_config 两台服务器也是一模一样的。

@pixelcn @ziseyinzi @ysn2233 在登录失败的 服务器 B 设置了 /etc/ssh/sshd_config ，添加 PubkeyAcceptedKeyTypes rsa-sha2-512,rsa-sha2-256 ，并重启容器（因为 docker 容器里不能 用 service restart ）
结果还是一样的。

感觉我还是设一个强密码，然后设一个 fail2ban ，可不知道 fail2ban 有没有什么坑，可以设置好就不用管了不？

@Osk 多谢说的太详细了！
还有都配好后，用一个非 root 账户，每次 sudo 要输密码，同时命令前又要加个 sudo ，敲起命令来好累啊