我太懂这种试遍各种方案却卡壳的憋屈感了！咱们一步步揪出问题所在，大概率是某个容易忽略的细节在搞鬼：

• 先验证sudoers语法是否正确
  虽然你用了visudo（它会自动检查语法），但保险起见可以手动验证所有sudoers相关文件：

  sudo visudo -c
  

  如果输出/etc/sudoers: parsed OK和所有sudoers.d文件的OK，说明语法没问题，排除这个坑。

• 警惕规则被后续配置覆盖
  sudo的规则是按顺序匹配，后出现的规则优先级更高。如果你的NOPASSWD规则之后，还有要求输入密码的规则（比如默认的%sudo ALL=(ALL:ALL) ALL组规则），就会直接覆盖你的无密码设置。

  • 如果你是在/etc/sudoers.d/10-extras里加的规则，要确保这个文件夹里没有编号更大的文件（比如20-defaults）包含了要求密码的规则；
  • 或者直接把你的用户规则放到/etc/sudoers文件里，放在所有组规则之后（比如%sudo那行的下面）。

• 检查用户所属组的规则优先级
  如果你的family用户属于sudo组（或者其他有sudo权限的组），组规则的优先级会高于用户单独的规则。比如默认的%sudo ALL=(ALL:ALL) ALL会强制要求密码，这时候即使你给用户单独加了NOPASSWD也没用。
  解决办法：要么修改组规则（给组加上对应的NOPASSWD权限），要么把用户的NOPASSWD规则放在组规则之后。

• 严格匹配命令的完整路径和参数
  你已经用which systemctl确认了路径，但测试的时候一定要用完全一致的命令执行：

  sudo /usr/bin/systemctl restart minecraft-bedrock.service
  

  别省略路径，也别漏了.service后缀，确保和sudoers里写的完全一样。

• 清除sudo密码缓存再测试
  sudo会缓存密码一段时间，有时候会干扰测试。先执行：

  sudo -k
  

  清除缓存后再试你的重启命令，看是否还提示密码。

• 排查AppArmor的影响
  Ubuntu默认启用AppArmor，虽然概率不高，但它可能会限制sudo的行为。可以临时关闭试试：

  sudo systemctl stop apparmor
  

  如果关闭后无密码生效了，再去调整AppArmor的相关规则即可。

要是连NOPASSWD: ALL都不行，那基本可以确定是规则被覆盖或者语法有隐藏问题，重点检查上面的前两条！

备注：内容来源于stack exchange，提问作者Jared