capistrano: scp: /tmp/git-ssh.sh: Permission denied

I think I’m too fried to see what’s happening here… Setup a new app to deploy with capv3 and I have no clue why this is happening. I have ssh auth passwordless setup correctly with the remote server… I can ssh and run any commands via ssh…

cap production git:check
DEBUG Uploading /tmp/git-ssh.sh 0.0%
cap aborted!
scp: /tmp/git-ssh.sh: Permission denied

Tasks: TOP => git:check => git:wrapper
(See full trace by running task with --trace)

full trace:

cap production git:check
DEBUG Uploading /tmp/git-ssh.sh 0.0%
cap aborted!
scp: /tmp/git-ssh.sh: Permission denied

Tasks: TOP => git:check => git:wrapper
(See full trace by running task with --trace)
mccme-rountrjf:ccpd-realtime joshua$
mccme-rountrjf:ccpd-realtime joshua$ cap production git:check --trace
** Invoke production (first_time)
** Execute production
** Invoke load:defaults (first_time)
** Execute load:defaults
** Invoke git:check (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
DEBUG Uploading /tmp/git-ssh.sh 0.0%
cap aborted!
scp: /tmp/git-ssh.sh: Permission denied
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-scp-1.1.2/lib/net/scp.rb:392:in `await_response_state'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-scp-1.1.2/lib/net/scp.rb:363:in `block (3 levels) in start_command'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:311:in `call'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:311:in `process'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:222:in `block in preprocess'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:222:in `each'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:222:in `preprocess'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:205:in `process'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `block in loop'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `loop'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `loop'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:269:in `wait'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/net-scp-1.1.2/lib/net/scp.rb:279:in `upload!'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:68:in `upload!'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/capistrano-3.0.0/lib/capistrano/tasks/git.rake:11:in `block (3 levels) in <top (required)>'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:42:in `instance_exec'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/sshkit-1.0.0/lib/sshkit/backends/netssh.rb:42:in `run'
/opt/boxen/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/sshkit-1.0.0/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
Tasks: TOP => git:check => git:wrapper

About this issue

Original URL
State: closed
Created 11 years ago
Reactions: 2
Comments: 22 (4 by maintainers)

Most upvoted comments

the issue might be the /tmp folder in your deployment machine does not have enough permission to run the script, change the folder /tmp folder to something else by set :tmp_dir, “/home/dh_user_name/tmp”

+26

bbiglari on Feb 18, 2014

Okay so, I believe the reason for the Permission denied is that I have a multi-user system and another user has deployed with capistrano3 and it’s created git-ssh.sh in /tmp with that user’s creds. Now another user trying to deploy capistrano3 cannot edit or delete or override that file due to it being owned by another person.

QUESTION: Is there not a way to configure capistrano3 to deploy to a sub folder of “tmp” so as to not conflict with other user’s space? Such as /tmp/<deploy_user>/git-ssh.sh

jfrux on Oct 14, 2013

Additional information, sometimes it’s considered security practice to mount /tmp with an option called noexec [1]. It’s not universal, which is why we choose /tmp as the storage place for the script, but there’s really no harm in setting :tmp_dir to the tmp directory in your application, or to the shared directory, or your deploy user’s home directory, wherever really.

[1] http://www.cyberciti.biz/faq/linux-add-nodev-nosuid-noexec-options-to-temporary-storage-partitions/

Lee Hambley

http://lee.hambley.name/ +49 (0) 170 298 5667

On 18 February 2014 19:52, Bahador Biglari notifications@github.com wrote:

the issue might be the /tmp folder in your deployment machine does not have enough permission to run the script, change the folder /tmp folder to something else by set :tmp_dir, “/home/dh_user_name/tmp”

— Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/687#issuecomment-35419084 .

leehambley on Feb 19, 2014

Another update, I’ve attempted to solve it by creating a “capistrano” user group and add all the “deploying” users to it and gave that group g+wrx permission on /tmp/git-ssh.sh but then capistrano decides it wants to CHANGE the permissions of the file…

DEBUG Uploading /tmp/git-ssh.sh 0.0%
 INFO Uploading /tmp/git-ssh.sh 100.0%
 INFO [e643f41f] Running /usr/bin/env chmod +x /tmp/git-ssh.sh on mccme-web.msbb.uc.edu
DEBUG [e643f41f] Command: /usr/bin/env chmod +x /tmp/git-ssh.sh
DEBUG [e643f41f]    chmod: changing permissions of `/tmp/git-ssh.sh'
DEBUG [e643f41f]    : Operation not permitted

I mean, I get why it needs it to be owned by the user so that the files that “git” pulls down don’t get owned by the root:capistrano but still… just wish I could find an alternative solution.

Back to the drawing board again…

jfrux on Oct 14, 2013