使用systemd启动Sharetribe服务时遇Errno::EACCES权限拒绝问题求助

作为部署过Sharetribe的开发者，我碰到过好几次这个问题——手动启动正常但systemd启动失败，核心原因几乎都是服务运行的用户和你手动启动的用户不一致，哪怕你设了777权限也没用。下面是一步步的解决方案：

1. 给systemd服务指定正确的运行用户 #

systemd默认可能用root或者nobody用户运行你的服务，而你手动启动时用的是自己的登录用户（比如ubuntu），这就导致权限不匹配。

• 编辑你的sharetribe.service文件：

  sudo nano /etc/systemd/system/sharetribe.service
  

• 在[Service]区块里添加或修改以下两行（替换成你的用户名和Sharetribe根目录路径）：

  User=ubuntu
  WorkingDirectory=/home/ubuntu/sharetribe
  

• 重新加载systemd配置并重启服务：

  sudo systemctl daemon-reload
  sudo systemctl restart sharetribe.service
  

2. 修复文件/目录的所有者（别依赖777） #

chmod 777虽然开放了所有权限，但如果文件的所有者是root，普通用户还是可能遇到隐性权限问题。正确的做法是把Sharetribe目录的所有者改成你指定的运行用户：

sudo chown -R ubuntu:ubuntu /home/ubuntu/sharetribe

（这里的ubuntu替换成你的实际用户名，路径替换成你的Sharetribe安装目录）

3. 检查AppArmor的限制（Ubuntu 16.04默认启用） #

Ubuntu 16.04自带的AppArmor可能会阻止Ruby进程访问某些路径，哪怕文件权限没问题。

• 查看当前AppArmor状态：

  sudo aa-status
  

• 如果发现有针对Ruby的profile在运行，可以临时禁用测试：

  sudo aa-disable /etc/apparmor.d/usr.bin.ruby
  

  （注意：这是临时测试用的，重启后会恢复。如果禁用后服务正常，你需要修改对应的AppArmor profile来允许Sharetribe访问相关路径）

4. 定位具体被拒绝的路径 #

查看完整的journalctl日志，找到Errno::EACCES后面跟着的具体文件/目录，比如：

Errno::EACCES: Permission denied @ rb_sysopen - /home/ubuntu/sharetribe/log/production.log

针对这个具体路径单独调整权限和所有者，比盲目给所有文件777更安全有效。

内容的提问来源于stack exchange，提问作者Arvind