25

I've read this answer about eight-five times, but there's something I'm not understanding correctly:

git-upload-pack: command not found, how to fix this correctly

When I try to clone a repository on my server, I get the following:

bash: git-upload-pack: command not found

But when I clone by giving clone the -u /usr/local/bin/git-upload-pack option, all works well.

I guess this makes sense, since that's the position of the git-upload-pack on my server.

The top answer suggests my .bashrc file on server needs to be updated to reflect this, as the result of ssh you@remotemachine echo \$PATH does not return /usr/local/bin. (It returns /usr/bin:/bin:/usr/sbin:/sbin).

But when I look at my .bashrc file, it contains:

export PATH=/usr/local/bin:$PATH

So now I'm confused.

What do I need to do to avoid using the -u /usr/local/bin/git-upload-pack option every time? Why does ssh you@remotemachine echo \$PATH not return /usr/local/bin? Is this something to do with login and non-login shells?

Please help! Thanks in advance.

Community
  • 1
  • 1
Chris
  • 523
  • 1
  • 6
  • 14
  • See [this part of the `bash` manual](http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files) – kostix Jun 21 '12 at 23:09

5 Answers5

26

This is connected to this issue:

https://serverfault.com/questions/130834/svnssh-getting-bash-to-load-my-path-over-ssh

Ssh is not loading your environment by default when sending a command without going to interactive mode.

good solution is the one with .ssh/environment file:

in /etc/ssh/sshd_config add:

PermitUserEnvironment yes

Then just create .ssh/ directory and dump envronment to .ssh/enviroment:

cd ~/
mkdir .ssh
env > .ssh/environment

Restart SSH

/etc/init.d/sshd restart

Now when you do this from your local machine:

ssh you@server.com  "which git-upload-pack"

you s'd get

/usr/local/bin/git-upload-pack

and git clone s'd work.

Community
  • 1
  • 1
madsheep
  • 416
  • 4
  • 6
  • 1
    I was trying to access a git repo on my mac using ssh. I had to edit the /etc/ssh/sshd_config and add "PermitUserEnvironment yes" and then restarted the sshd thru System preferences->Sharing->Remove Login. I didn't have to create the .ssh/environment file – user674669 Jun 11 '13 at 15:20
  • Looks like a typo in the restart command. Shouldn't it be: /etc/init.d/ssh restart ? – javydreamercsw Jul 21 '16 at 16:58
12

Yes, it is to do with login and non-login shells. The .bashrc file only gets loaded in non-login shells. You can use .bash_profile for login shells. Just add the same modification to your PATH in the .bash_profile file and you should be good.

export PATH=/usr/local/bin:$PATH

You may find this is an interesting article on the difference between .bashrc and .bash_profile, and login and non-login shells.

Nathan Kleyn
  • 5,103
  • 3
  • 32
  • 49
  • Thanks! Makes perfect sense – but doesn't seem to work for me. Both my `.bash_profile` and `.bashrc` contain the code `export PATH=/usr/local/bin:$PATH`, but this isn't doing the trick. `ssh you@remotemachine echo \$PATH` still returns `/usr/bin:/bin:/usr/sbin:/sbin`. Possible reasons? (Guesses.) 1. I'm on a Media Temple server and there's a .bash_mt_profile file. (But I added `export PATH=/usr/local/bin:$PATH` for good measure and it didn't seem to work.) 2. I'm logged in as root. 3. I'm not using bash (but when I log in, it says I can edit my `.bash_profile` to remove system messages. – Chris Jun 26 '12 at 21:31
  • @Chris: Out of interest, does your `.bash_profile`/`.bashrc` file have the perms set to 644, is owned by the correct user, and has no executable bit set? The file is sourced, not executed, but must be owned by the user who is attempting the source and must have 644 (or greater) perms. If it keeps failing for you after checking these, you could always try adding the PATH change to `/etc/profile` or `/etc/profile.d/*` (depending on your distro). – Nathan Kleyn Jun 27 '12 at 08:02
  • Thanks again. Yes, perms are 644. I reset them anyway. It didn't work. Added a file called git.sh to `/etc/profile.d/` with the code `export PATH=/usr/local/bin:$PATH` (is that the correct thing to do?) and that hasn't worked either. I can only assume I've not done something blindingly obvious. – Chris Jun 27 '12 at 19:00
  • Yeah, that is the right code. Only thing I can think of is that maybe the `git.sh` file isn't executable, try `chmod +x` to see if that makes a difference? Other than that, it sounds like the MT servers are perhaps hardcoding the `PATH` variable at a lower level somewhere? – Nathan Kleyn Jun 27 '12 at 22:34
  • I had a similar issue, where I didn't have root access. So for me this answer is more superior than the accepted answer. – Darwayne Sep 19 '13 at 17:12
7

I solved this issue in my case by logging into the remote machine, a Ubuntu box, and doing sudo apt-get install git. Not sure if this is overkill or not, but solved the problem for me instantly.

Raja Simon
  • 10,126
  • 5
  • 43
  • 74
Hugh Perkins
  • 7,975
  • 7
  • 63
  • 71
  • At first I thought `git-upload-pack` was just a missing dependency in the client environment, but it wasn't missing. Then this answer helped me realize that the "command not found" error was actually referring to the *remote environment* (in my case, a Raspberry Pi connected to the LAN), which didn't have Git installed. – crimson_king Dec 13 '20 at 04:52
2

My solution for this problem

  1. Check path for the git-upload-pack on your remote machine:

    ssh yourname@IP-addressORdomain 'which git-upload-pack'
    

If it gives a path - copy it (without git-upload-pack and trailing slash. Examples: /usr/bin, /home/yourname/bin, /whatever/gituploadpack/path, etc.).

  1. Check your PATH on the remote machine during login shell:

    ssh yourname@IP-addressORdomain 'echo $PATH'
    

There is no such a path (/whatever/gituploadpack/path), is not it? Good!

  1. Login to your remote machine:

    ssh yourname@IP-addressORdomain
    
  2. Open .bashrc_profile:

    nano /home/yourname/.bashrc_profile
    
  3. Find these lines if any:

    if [ -f ~/.bashrc ]; then
         ~/.bashrc
    fi
    

...and change them for:

    if [ -f ~/.bashrc ]; then
        source ~/.bashrc
    fi
  1. Open .bashrc:

    nano /home/yourname/.bashrc
    
  2. Add these 4 lines:

    if [ -d "/whatever/gituploadpack/path" ] ; then
      PATH="$PATH:/whatever/gituploadpack/path"
    fi
    export PATH
    
  3. Exit the remote machine:

    exit
    
  4. Check your PATH on the remote machine during login shell:

    ssh yourname@IP-addressORdomain 'echo $PATH'
    

Do you see /whatever/gituploadpack/path? Congrats!

Note now you've solved not only git-upload-pack problem but also git-receive-pack and other executables on your /whatever/gituploadpack/path!

Unihedron
  • 10,902
  • 13
  • 62
  • 72
drugan
  • 789
  • 9
  • 10
0

I was getting the following errors: git-credential-osxkeychain died of signal 11 When I was doing git pull, I would get fatal: https://github.com/.../../info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?

I am guessing it had to do with my previous invalid github credentials in the keychain.

  • Opened keychain access tool using Command space
  • searched for github in the keychain access tool
  • removed all the entries related to github (since I no longer needed it)
  • followed the setup git password caching section again setup git
  • it worked

Incase any of the above answers does not help.

ssinganamalla
  • 1,250
  • 3
  • 12
  • 19