吐槽
Copyparty 是一个功能强大的便携式文件服务器,相对于我使用过的Transfer.sh和FileCodeBox,其更注重于文件管理方面而非分享。
然而我看中这个项目的原因是其不会对我上传的文件进行莫名奇妙的命名和没有杂乱的管理系统。
FileCodeBox
FileCodeBox的前端页面能够方便的设置文件的过期时间,超过指定时间后删除,但是删除之后却不会删掉其占用的文件夹,长此以往其数据文件夹就会杂乱不堪,留下一堆不明文件夹,不知道里面到底是空的还是有文件。
并且FileCodeBox的前端实在是太臃肿了,虽然很好看,但是加载就要花许多时间。管理界面的功能也很少,甚至无法对已上传的文件进行预览查看,只能使用那个取件码进行下载后查看。
Transfer.sh
而Transfer.sh就简洁的很,不过又简洁的过头了。其定位更多的是在命令行使用,没有复杂的前端界面,只有一个静态页面用来显示各种操作提示和基础的上传删除功能,还有一个预览界面。这个文件预览界面甚至精简成了同一个URL使用不同请求头请求不同文件的地步,导致CDN都出现了故障。
而这都是小事,能够简单的解决。其最大的问题是默认不设置文件保留时间,并且没有任何管理界面。于是在长时间使用之后就会在服务器上留下一对无主文件,不仅使用混乱的命名,而且套了两层文件夹。第二层文件夹是delete-token,用来删除文件。没错,删除文件还需要手动使用正确的delete-token手动删除,并且这个delete-token只会在上传之后返回一次,之后就无从得知了。对于文件积累的问题这两个项目都没有好好解决。
Docker容器部署
接下来使用Docker来将其部署到服务器上。
仓库中有自带的Docker部署指南,不过有一些配置要点没有讲明白。
命令解释
以下是仓库中提供的配置命令
docker run --rm -it -u 1000 -p 3923:3923 -v /mnt/nas:/w -v $PWD/cfgdir:/cfg copyparty/ac
其中的--rm会在关闭容器后自动删除,可以不加这个参数,这样关闭容器后可以随时重启。
-u 1000参数是指定以用户ID 1000运行容器(通常是第一个普通用户),但是不适用于所有情况。建议先使用该参数尝试部署,如果出现了Permission deny这样的权限问题,先检查访问的目录权限,如上面的/mnt/nas,解决权限问题后应当可以正常使用。若始终无法解决权限问题或者觉得太麻烦了,可以改为使用-u 0来使用root用户运行容器,这可以解决大多数权限问题。
-p 3923:3923这个参数是用来指定开放的端口,前面一个是服务器对外的端口,后面一个是容器内部的端口。前面的服务器端口可以自行修改为可用端口,一般保持默认即可。后面的端口需要与项目代码中的端口一致,不建议修改。
-v /mnt/nas:/w用来挂载服务器路径到容器内部。冒号前面的路径是服务器要使用的路径,冒号后面是挂载到容器内部的路径,不能使用根目录/,运行会报错。/w是项目使用的默认文件夹,在项目的配置文件中当前目录.就对应这个文件夹。要注意的是每挂载一个不同的路径都要用-v参数指定。
目录看起来非常乱,这就是项目的问题所在了,不过搞清楚之后就能好好玩了。
-v $PWD/cfgdir:/cfg这个参数用来指定将当前文件夹下的cfgdir文件夹挂载为容器内的cfg文件夹。$PWD就是当前用户所处的文件夹,使用Linux的pwd命令就可以查看当前所处的路径。运行docker路径时所处的路径就会替换$PWD的值。若是不想切来切去可以改为绝对路径,就和上一个参数一样。容器内的/cfg是项目默认的配置文件位置,执行命令之前需要先将配置文件放在里面,否则项目无法运行。
copyparty/ac指定使用的镜像为Docker Hub 官方镜像上的ac版本。若要使用github上的镜像,可以改为ghcr.io/9001/copyparty-ac。关于不同版本的说明在原文档中有,这里只给出翻译。
版本说明
各版本在安装后及经 gzip 压缩的镜像大小如下:
min(57 MiB, 20 gz) 仅包含 copyparty 本体im(70 MiB, 25 gz) 支持使用 pillow 生成图像缩略图,通过 mutagen 解析媒体文件ac(163 MiB, 56 gz) 在im基础上增加 ffmpeg,支持音视频缩略图生成、音频转码及更完善的元数据解析iv(211 MiB, 73 gz) 在ac基础上集成 vips,加速 HEIF/AVIF/JXL 格式的缩略图生成dj(309 MiB, 104 gz) 在iv基础上加入 beatroot/keyfinder,支持音乐调性与 BPM 检测推荐使用
ac版本,因为iv和dj的附加功能在实际使用中需求较少多数版本支持
x86、x86_64、armhf、aarch64、ppc64le、s390x架构:
dj不支持ppc64le、s390x、armhf架构
iv不支持ppc64le、s390x架构注意:以下版本为未完成的实验性构建,未公开发布:djd djf djff dju
作者推荐使用ac版本,若要更换其他版本,只需要将ac改为其他的代号。
配置文件及参数简要介绍
上面说过,在cfg文件夹中需要放入配置文件才能让项目正常运行。而要放到容器内的cfg文件夹里,只需要将配置文件放在其映射的cfgdir文件夹中即可。
以下几个是仓库中的示例文件,其中第三个配置文件中介绍了各种参数的作用。
copyparty.conf
example.conf
chungus.conf
以第一个copyparty.conf为例
# not actually YAML but lets pretend:
# -*- mode: yaml -*-
# vim: ft=yaml:
[global]
e2dsa # enable file indexing and filesystem scanning
e2ts # enable multimedia indexing
ansi # enable colors in log messages (both in logfiles and stdout)
# q, lo: /cfg/log/%Y-%m%d.log # log to file instead of docker
# p: 3939 # listen on another port
# ipa: 10.89. # only allow connections from 10.89.*
# df: 16 # stop accepting uploads if less than 16 GB free disk space
# ver # show copyparty version in the controlpanel
# grid # show thumbnails/grid-view by default
# theme: 2 # monokai
# name: datasaver # change the server-name that's displayed in the browser
# stats, nos-dup # enable the prometheus endpoint, but disable the dupes counter (too slow)
# no-robots, force-js # make it harder for search engines to read your server
[accounts]
ed: wark # username: password
[/] # create a volume at "/" (the webroot), which will
/w # share /w (the docker data volume)
accs:
rw: * # everyone gets read-write access, but
rwmda: ed # the user "ed" gets read-write-move-delete-admin
配置文件基本可以分为三个部分
- global
- accounts
- mount
global
全局参数,用来全局调控设置,其中的参数可以从仓库中的第三个演示配置chungus.conf中找到对应的解释。可以配合deepwiki来找到想要的参数。
accounts
用来添加不同的用户,冒号前面是用户名称,后面是用户密码。在网页url后面加上?h之后就可以进入登录页面,输入用户密码就可以登录对应的账户。
所以大概每个用户不能有一样的密码。
mount
挂载部分,重点介绍。
这部分没有对应的头,直接在前面两个部分之下添加即可将卷挂载到网页上。
[/] # 在网页上显示的目录
/w # docker容器内的路径,若使用`.`则会将默认选择/w。
accs: # 用户权限管理
rw: * # * 星号为通配符,表示所有未登录用户和未指定权限用户的基本权限
rwmda: ed # 用户ed具有 读、写、移动、删除、管理 权限
flag: # 对该目录指定专门的参数,参数内容在chungus.conf中有介绍
e2d
用户权限的参数在chungus.conf中有介绍:
r: username_who_gets_Read_access
w: username_who_gets_Write_access
m: username_who_gets_Move_access
d: username_who_gets_Delete_access
.: username_who_can_see_Dotfiles
g: username_who_gets_Get_access
G: username_who_gets_upGet_access
h: username_who_gets_html_access
a: username_who_gets_admin_access
A: username_who_gets_ReadWriteMoveDeleteDotfileAdmin_access
对于路径映射需要详细说明,这部分对我造成了巨大的困扰。
首先是Docker容器与硬盘的映射,在创建容器时指定,将硬盘中的路径挂载到容器内部。容器内只会有挂载后的目录。
这里假设创建Docker容器时进行了以下的挂载
/mnt/nas -> /w
~/cfgdir -> /cfg
~/music -> /w/music
那么容器内部就只会有这些路径
/
├── cfg/ # 挂载自 ~/cfgdir
└── w/ # 挂载自 /mnt/nas
└── music/ # 挂载自 ~/music (覆盖了/w/music)
而配置文件是将容器内部的目录映射到网页上显示。如上面的copyparty.conf就是将容器内的/w目录映射到网页上显示为根目录。
以下两种写法是等同的,因为copyparty默认会将容器内部的/w设置为当前路径。
[/]
/w
[/]
.
若是像下面,尝试将硬盘中的路径直接映射到网页路径上就会报错,因为在容器内部并没有/mnt/nas这个路径。
[/]
/mnt/nas
继续部署
理解了映射之后再进行部署就非常简单了,先写好配置文件,将其放到某个文件夹内,再修改Docker命令将其挂载至容器内的/cfg目录,最后直接运行Docker命令即可。
部署之后就可以通过 ip + 端口 访问网页,之后的细节就自己配置了。修改完配置文件只需要重启容器就可以生效。
之后若想要公网访问,可以使用内网穿透服务或者利用ipv6。内网穿透可参考这篇Cloudflare Tunnel的教程。