由于容器和宿主机共用了一套内核，因此同一个uid对应的容器用户和宿主机用户(哪怕用户名不同)对于内核权限控制而言都是同一个用户。而默认情况下，如果未做特殊配置，容器里的进程默认是以root用户运行的。



这里就有两个问题：

直接以root权限运行容器不安全
以其他用户运行容器可能因为挂载宿主机目录的权限问题而蛋疼

先说第二个问题：

导致这个问题的原因，一般是因为容器内该uid的用户对宿主目录无权限导致的。 比如，容器里的mysql用户的uid是2000，而宿主当前mysql用户uid是1000，即便宿主要挂载的目录权限是mysql:mysql，容器里看到的权限也是1000:1000而权限被拒绝。

还有一种情况，宿主不存在被挂载的目录。 Docker会以root权限先创建该目录再挂载。 这就导致以普通用户运行的容器进程无权限访问该目录

这个问题最简单的处理方式就是先手动chmod 777 或者chown 2000:2000 ，再启动容器。不过这不是长久之计也违背了docker的初衷。

对于这个问题，目前大家最好的处理方式，就在entrypoint脚本里先对需要本地挂载的目录做权限配置，再启动服务。因为执行entrypoint脚本则是在启动阶段（start）所以在entrypoint.sh中可以对volume做权限配置。 当然，权限配置需要root权限，这就需要以root启动容器。

第一个问题：

以root权限运行容器，会导致容器中的进程有了适当的机会，它就可以控制宿主机上的一切！如何解决比较好呢？

有些服务可以直接以root启用，并配置其他用户运行。

比如：

mysqld可以mysqld --defaults-file=/etc/my.cnf --user=mysql

memcached可以memcached -u www

甚至像ngx php-fpm 这类的服务可以直接在配置文件里指定运行worker进程的用户而master进程保持root运行

挂宿主目录的权限问题

```shell
if sudo docker cp e5c8fe8a5d30:/home/node/trilium-data/backup/backup-now.db /home/pi/trilium-data/;
then echo "$(date "+%Y-%m-%d %H:%M:%S") Backup Finished !\n" >> /home/pi/pi-scripts/logs/log.txt;
else echo "$(date "+%Y-%m-%d %H:%M:%S") Backup Failed !\n" >> /home/pi/pi-scripts/logs/log.txt;
fi
```
使用的是 `Docker cp` 命令 配合 Bash script 和 Linux 下的 `Crontab` 进行自动定时备份



需要知道容器的 id 使用

`sudo docker ps`

来查询





参考：Shell流程控制 、Crontab