问题：

我正尝试在无根模式下通过Docker部署一个 推理服务，但遇到了以下错误：

[+] up 31/33 ⠦ Image xprobe/xinference:latest [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿] 14.88GB / 14.9GB  Pulling                                                                                                                                                                  226.7s failed to extract layer (application/vnd.docker.image.rootfs.diff.tar.gzip sha256:2212a3b3ee926008d05499e564f59f5d56be95efd84b3d6937165093c3d6d6a0) to overlayfs as "extract-163690835-3LXC sha256:1274089c0e547b7b64522f2a71d0494b59fa43dd08a2ce2c903c77e0e6319876": mount callback failed on /home/lu_dify/.local/share/docker/containerd/daemon/tmpmounts/containerd-mount638215195: failed to Lchown "/home/lu_dify/.local/share/docker/containerd/daemon/tmpmounts/containerd-mount638215195/opt/inference/openfst-1.7.2" for UID 304185, GID 89939: lchown /home/lu_dify/.local/share/docker/containerd/daemon/tmpmounts/containerd-mount638215195/opt/inference/openfst-1.7.2: invalid argument (Hint: try increasing the number of subordinate IDs in /etc/subuid and /etc/subgid)

在普通的（具有root访问权限的）Docker中部署时一切正常。

仓库中的相关问题。

尝试的解决方案：

我已经为无根模式下的用户增加了分配的ID范围，但据我了解，导致问题的异常应该在该范围内，问题仍然存在。

用户ID范围：lu_dify:231072:262144（常规65,536的 4倍）

难道镜像需要GID 89939吗？这个范围应该能容纳这么高的ID，但起始点显然超过了它。UID 304185应该也在范围内。

我不太愿意进一步扩大分配范围，因为不确定这是否会给系统的未来用户带来问题。

对此主题的任何建议，以及最大推荐的ID范围，将不胜感激！

解决方案

问题之所以存在，是因为容器试图使用一个不在用户分配的GID范围内的GID（组ID）。错误信息明确提到GID 89939。为解决此问题，需要将该用户的GID范围扩展以包含89939。

下面是修复方法：

1. 扩展GID范围：

echo 'lu_dify:89939:1' | sudo tee -a /etc/subgid

此命令向 /etc/subgid 文件追加新的一行，为用户 lu_dify 分配GID 89939。

1. 重启Docker守护进程以应用更改：

bash sudo systemctl restart docker

这应该通过确保GID 89939可用于该用户来解决问题。如果还需要其他GID，请为每个缺失的GID重复此过程。错误中提到的UID（用户ID）并不是问题所在，因为它已在分配范围内。

如有需要，请将 lu_dify 替换为相应的用户名。如果遇到进一步的问题，请确保Docker守护进程具有适当的权限，并且没有其他进程与GID分配冲突。