Issue
Ansible commands executed through the EC-Ansible plugin fail with permission denied errors.
Job logs show the parameter --become-user=<non-root-user>, indicating that Ansible is attempting to escalate privileges by switching to a regular user account rather than root.
Since the regular user lacks the necessary permissions to execute the required commands, the job fails.
This prevents Ansible playbooks from executing commands that require elevated privileges.
Explanation
The EC-Ansible plugin uses Ansible’s privilege escalation mechanism (become) to execute commands with elevated permissions. The plugin configuration includes a "become credential" section that specifies:
-
Username: The user account Ansible should switch to for privilege escalation
-
Password: The password used for authentication
When the become credential username is incorrectly set to a regular user instead of "root", Ansible attempts to switch to that user for command execution.
Since regular users typically lack the permissions needed for administrative tasks, commands fail with permission errors.
The job logs reveal this misconfiguration through the --become-user parameter, showing a non-root user.
Resolution
Correct the EC-Ansible become credential configuration:
-
Review the job logs to confirm the presence of
--become-user=<non-root-user>indicating the misconfiguration -
Navigate to the CloudBees CD interface and access the EC-Ansible plugin configuration
-
Locate the become credential settings for the affected procedure or configuration
-
Set the username field to
root(not the SSH user) -
Set the password field to the SSH user’s password
-
Click Save or OK to apply the changes
-
Re-run the Ansible procedure to verify the permission errors are resolved
This configuration allows Ansible to authenticate using the regular user’s credentials while escalating privileges to root for command execution.