我在 AWS 上有一个 Ubuntu 暂存服务器，它使用 Thin Web 服务器运行一个小型 Sinatra 应用程序。sinatra
应用程序git clone在调用时运行一些命令，当我rackup从我的用户运行它时，一切都运行良好。
自然，我想将服务器作为守护进程运行，为此我使用rackup -D并调用了该应用程序。这次，我从 git 收到一个异常，它告诉守护进程无权写入目标文件夹：
could not create work tree dir 'path/to/clone': Permission denied
据我了解，守护进程具有与运行它们的用户相同的权限，那么任务为什么会失败？我也尝试了chmod -R 777目录，但没有用。
答案1
我的问题最终出在机架本身。结果（正如解释的那样这里) 该 rack 在与rackup -D命令一起运行时（作为守护进程）会将工作目录更改为/。
答案2
检查可执行文件是否设置了 setuid 位。这将使其以文件所有者的身份运行，而不是启动该文件的用户。您可以通过运行ls -l appname并查看权限掩码中的第四个字符（代替所有者可执行位）来检查。如果是，s则设置了 setuid 位。
守护进程通常设置为使用 setuid 运行，因此它们应该不是拥有启动它们的用户的权限。这与非守护进程应用程序不同，后者是需要具有用户的权限。您需要将守护进程的用户 r 添加到您想要影响的文件的组中，并确保组权限允许执行这些操作。