Packer: file provisioner permission denied

Created on 1 Oct 2014  ยท  9Comments  ยท  Source: hashicorp/packer

$ packer --version
Packer v0.7.1

When using the file provisioner, and pre-creating a folder using sudo, I get a permission denied error:

errored: scp: /etc/chef/cookbooks: Permission denied

Using debug I can see the folder being created (as root), so it does exist, but I guess the folder is being scp'd as the ssh_username, which I can understand, but it causes problems like these. Maybe it should be uploaded to a temporary location and then be moved as root?

Most helpful comment

The documentation here is not clear at all. It's not a "recommendation" if it's a "requirement", for one thing. Throwing down a line on it's own that says-

Warning: You can only upload files to locations that the provisioning user (generally not root) has permission to access. Creating files in /tmp and using a shell provisioner to move them into the final location is the only way to upload files to root owned locations.

All 9 comments

Actually, after adding chown (and back) script provisioners, I now get the error again using the chef-client provisioner:

errored: Error creating Chef config file: scp: /tmp/packer-chef-client/client.rb: Permission denied

Again, this can be resolved by creating /tmp/packer-chef-client manually and chowning it to ubuntu (or whatever the ssh_username is set to).

However, I keep running into weird issues (almost as if I am using Packer wrong (I am following along with the website documentation).

I've overwritten the execute_command like so:

"execute_command": "{{if .Sudo}}sudo {{end}}chef-client --local-mode --no-color -c {{.ConfigPath}} -j {{.JsonPath}}",

but now I get the following error:

Executing Chef: chef-client --local-mode --no-color -c <no value> -j <no value>
bash: -c: line 0: syntax error near unexpected token `newline'
bash: -c: line 0: `chef-client --local-mode --no-color -c <no value> -j <no value>'

Somehow, the variables {{.ConfigPath}} and {{.JsonPath}} aren't set, even though the documentation suggest they are by default. This can of course be circumvented by setting the paths manually, but it is still unexpected behaviour.

edit I also noticed the {{if .Sudo}} failed to trigger, so I had to manually add sudo to the command.

Yep, sorry, I believe the documentation states that you should upload to somewhere you have write access, then use a shell provisioner to move things over. I stand by this since supporting automatic copy is a little too magical for my taste.

It doesn't seem like the docs mention this (https://www.packer.io/docs/provisioners/file.html)...

actually it's somehow described in the first paragraph.
my workaround is using the salt-masterless provisioner and handle all things with salt (which may be removed afterwards).

@jcrben @pille if either of you have recommendations for a better place to document this gotcha, I'd gladly review a PR on the salt provisioner docs.

The documentation here is not clear at all. It's not a "recommendation" if it's a "requirement", for one thing. Throwing down a line on it's own that says-

Warning: You can only upload files to locations that the provisioning user (generally not root) has permission to access. Creating files in /tmp and using a shell provisioner to move them into the final location is the only way to upload files to root owned locations.

I build my Packer scripts with a Ruby script, and it would be nice to have a prettier solution here even though I understand why the current limitation is in place:

def upload_file(target, destination)
  random_file = "/tmp/#{rand(36**36).to_s(36)}.consultemp"
  [
    {
      type: "file",
      source: target,
      destination: random_file,
    },
    {
      type: "shell",
      inline: [
        "sudo cp #{random_file} #{destination}"
        "rm #{random_file}"
      ],
    }
  ]
end

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings