Preface
When we usually want to share a file with a friend, it generally comes down to the following 2 ways:
Via cloud drive
By uploading to a cloud drive (such as Baidu Wangpan, Aliyun Drive, etc.) and sharing it as a link, the recipient needs to save it to their own cloud drive or download it directly to play. Both the sender and the recipient may be affected by factors such as whether they are paid members.
Direct sending via WeChat or QQ
Sending files directly through WeChat has size limits; it doesn't matter for small files, but large files cannot be sent directly through WeChat. Actually, sending files via QQ does have some advantages, but offline sending also has limits (2G or 4G, I can't remember clearly, and it seems to be related to membership status), while online sending has no limits but requires both parties to be online, and the speed is hard to say.
All things considered, there is surprisingly no perfect way to share a file normally.
At this time, the Cloud Object Storage (COS) solution becomes the best choice. It can generate an http(s) link for various types of files to share, allowing direct download or online opening, making it a handy helper in daily life. In fact, various cloud service providers offer COS services, and looking at Tencent Cloud, the price is not expensive, and individuals even get a free quota of 50GB (for 6 months). However, adhering to the principle of building a home data center where self-hostable services should absolutely not cost money, let's build a free COS ourselves. Currently, the best open-source free object storage is minio, and we will use the simplest docker deployment method.
Deploying minio COS
The minio docker repository actually contains several components, but generally speaking, our minimal deployment only requires a server side. Deploying only the server side has an issue where the shared link is valid for a maximum of 7 days. If this duration is enough for you, there's no need to fuss, just a server side is enough. However, if you want to set it to be permanently valid (for example, to use on a webpage), then you need to install a client side to configure policies for the buckets on the server side.
Installing minio server side
Since a bridge named public-net will be used below, it needs to be created in advance:
docker network create public-net
Deploying minio server side:
The command is as follows:
docker run --name minioserver -d --restart=always --network=public-net -v /docker/minio/data:/data -p 9000:9000 -p 9001:9001 -e "MINIO_ROOT_USER=root" -e "MINIO_ROOT_PASSWORD=123" \ minio/minio server /data --console-address ":9001"
Parameter explanations are as follows:
-v /docker/minio/data:/data Map the host machine's /docker/minio/data directory to the /data directory inside the container
-p 9000:9000 -p 9001:9001 Map the host machine's ports 9000 and 9001 to the container's ports 9000 and 9001 respectively
-e "MINIO_ROOT_USER=root" -e "MINIO_ROOT_PASSWORD=123" Specify the login username and password for the minio server. If not specified, the default login username and password are bothminioadmin
server /data Start the server side and use the /data directory as the data directory
--console-address ":9001" Specify port 9001 as the console port
After the container starts, you can log in to the console directly using http://host_ip:9001.
The management unit in COS is buckets. By default, there are no buckets, so you need to create a bucket first:

Here I have already created a bucket named video, as shown in the image above. Click into this video bucket, and then click the Browse Buckets button in the red box in the upper right corner:

At this point, you can enter the bucket. Here, you can directly upload files via Upload in the red box in the upper right corner, or use the Create new path button in the red box in the lower right corner to create a category folder first before uploading files. For example, in the image below, I created an mtv folder:

In the mtv folder, I uploaded 2 mtvs:

Logically speaking, you can start sharing now. There are 2 ways:
Select the file in the web interface and directly generate a sharing link:


The advantage of this method is that you can specify the validity time of the sharing link (maximum 7 days, minimum 1 minute). The disadvantage is that the link is too long, and this link cannot be used directly. If it is to be used on the intranet, you need to change 127.0.0.1 to the host machine's intranet IP address; if it is to be used on the extranet, you need to change it to the reverse proxy domain name or the cloud host's public IP (if it is not a standard port, such as 80 and 443, you also need to add the specific port).
Directly splice the address manually:
Intranet use:http://宿主机内网IP:9000/mtv/斑马斑马.mp4
Extranet use:https://反向代理公网IP或域名:端口/mtv/斑马斑马.mp4, where the port is only added when using a non-standard port. For example, with my home broadband, if it is port 80 or 443, there is no need to add it.
This method is obviously much more efficient and is the recommended way, but the disadvantage is that you cannot customize the time, and it can only expire in the default 7 days.
Whether it is the 1st or 2nd method, if you want to publish through a reverse proxy, you need to set up the reverse proxy first. There are many tutorials on setting up reverse proxies online, so I won't repeat them. However, there is a key point here, which is also very tricky: look at the sharing link in the previous web interface:

Actually, just looking at this might not make you think of it, but after setting up the reverse proxy later, it kept failing and reported the following error:

At first, I didn't think about the host address and port. After struggling for a long time, I suddenly thought, they wouldn't be so boring as to restrict the host and port, right? Then, on the reverse proxy (taking the BT Linux Panel as an example), I set it to pass the domain name and port:

And then it worked... The minio server's docker actually restricted the host address and port to 127.0.0.1:9000. This really set me up, who would have thought of that...?
In short, up to this point, it is actually enough for most people. The 7-day limit is fine under normal use, but what about under abnormal environments? For example, when you want to use it on a webpage or blog...
If you want to break the 7-day limit, you have to use the minio client.
Installing minio client:
The command is as follows:
docker run -it --name minioclient -d --restart=always --network=public-net --entrypoint=/bin/sh minio/mc
After docker is up, directly enter the command line inside the minioclient container (or you can use docker exec, depending on your habit):
Bind the already established minio server in the minio client, the command format is as follows:
mc alias set <alias> <your-minio-endpoint> [YOUR-ACCESS-KEY] [YOUR-SECRET-KEY]
Where alias is the alias of the minio server; your-minio-endpoint is the access link of the minio server. Taking my environment as an example, the IP address of the docker host is 192.168.10.130, and the port is 9000, so the access link ishttp://192.168.10.130:9000 ; YOUR-ACCESS-KEY and YOUR-SECRET-KEY need to be generated on the minio server, as shown in the figure below:

Taking my environment as an example, the actual command is as follows:
mc config host add minio http://192.168.10.130:9000 YOUR-ACCESS-KEY YOUR-SECRET-KEY --api S3v4
Normally, it will display:

Use the mc ls command to view the contents of the storage just created:
mc ls minio
Normally, you will see the bucket we created earlier:

Use the mc alias ls command to view the newly created alias minio
mc alias ls minio

Using the mc anonymous command, you can see that there are 4 policies, as shown in the red box below:

Among them, upload corresponds to write-only, and download corresponds to read-only. We need to set the bucket video to download:
mc anonymous set download minio/video

All done.