最近为团队服务，折腾jupyerlab和jupyterhub。 而且我们是对外提供服务，为了网站安全，使用docker运行上述两者。hub spawn lab的形式。 最初自己使用jupyterhub的时候就遇到各类权限问题，如果不是容器安装，这主要是启动jupyterlab的用户和文件目录的所有用户不一致，导致无法创建或保存文件等，出现permission denied提示。网上大家给的建议基本上是把本地用户目录直接chmod 777来给所有权限。自己玩单机当然可以，但是对外服务肯定不好，这里只需要要jupyterlab映射的工作目录与启动jupyterlab的用户相同即可。 然而，使用docker启动时，方案就没那么简洁了。其实出问题的还是权限，但是是用户自身uid下对应的权限。这里直接说要点：docker中默认用户jovyan的uid是1000，可以通过cat /etc/passwd查看。 而如果启动docker是-v上去的目录用户不是这个uid（只有linux的第一个用户是1000，其他用户都是这个uid继续累加的），则死活都是permission denied（chmod 777不算的）。如果是单人使用，可以把要挂载的目录，直接chown 1000.1000 -R即可。 我这里遇到的问题更尴尬，临时更换jupyterlab和hub的主机，且默认的1000用户的用户名不一致，如A（原始主机）1000用户名为userA，而B（目的主机）1000的用户名为userB，而1001的用户名为userA。则简单的压缩A上的目录到B，发现权限不对，因为默认压缩时，记录了用户名，解压时，优先匹配了用户名。这是在tar -cf压缩时，最后带上--numeric-owner，这样不记录用户名，只记录id数字。解压时，按照id数字解压，自动对上当前机器的用户名，虽然看着用户名不对了，但是对于jupyterlab来讲，用户名/id是对得上的。 这里扩展一点，就是启动lab时，可以霸王的使用-u root，则jupyterlab就一直有root权限来跑程序，可能威胁主机安全。 而我这里遇到额外的事情是hub不是我准备的，感觉其内部默认就是root权限，建立了root权利的目录，导致lab使用时，该文件夹不能为外部指定的绝对路径，只能是volumes里面的目录。这个有待再确认。 Last modification：November 22, 2022 © Allow specification reprint Support Appreciate the author AliPayWeChat Like 送杯咖啡，做个交流，谢谢！
