Problems with first upload to github

Question

My first upload to github and I'm having the following issue with the command:

dan@dan-netbook:/opt/lampp/htdocs/myProject$ git push origin master  
error: unable to create directory for .git/refs/remotes/origin/master
error: Cannot lock the ref 'refs/remotes/origin/master'.  
Everything up-to-date  

I get this error while following the instructions given at github.com. Is anyone familiar with this type of error?

Running the command with sudo returns:
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Running - ssh -v [email protected] returns:

OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: Connection established.
debug1: identity file /home/dan/.ssh/identity type -1
debug1: identity file /home/dan/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/dan/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2
debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received  
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/dan/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/dan/.ssh/id_rsa
debug1: Remote: Forced command: gerve danwoods
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Remote: Forced command: gerve danwoods
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
PTY allocation request failed on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
ERROR: Hi danwoods! You've successfully authenticated, but GitHub does not provide shell access
                                                                                               debug1: channel 0: free: client-session, nchannels 1
Connection to github.com closed.
Transferred: sent 2576, received 2904 bytes, in 1.8 seconds
Bytes per second: sent 1469.6, received 1656.7
debug1: Exit status 1

Answer 1

It looks like you have a local permission problem. There is nothing specific to Git about this problem. The hierarchy could contain anything and these instructions would be exactly the same. By default, Git will honor the umask setting that is described later (unless it is overridden by a core.sharedRepository configuration).

In your comments you said that your user will be the one updating the contents of the hierarchy and you will also have a web server that will be reading the contents of the hierarchy. I will assume that the web server is running under some other user (this usually the case (e.g. Apache running as user httpd)). Further, I will assume that is acceptable if other users on this same machine can also read the contents of the hierarchy (the required permission scheme for such a configuration is more complicated—it involves using a special group and making sure your files and directories have that group as their ‘group owner’).

Facts

• The hierarchy of concern is rooted at: /opt/lammp/htdocs/myProject
• Local user dan needs to be able modify the contents of the hierarchy at will.
• A web server (probably running as some other user) needs to be able to read the contents of the hierarchy.
• It is OK if other users on the local machine can read the contents of the hierarchy.

Solution

• Have dan be the ‘user owner’ of all of the hierarchy. The ‘group owner’ is not important.
• Give the ‘user owner’ (dan) read, write, and execute permissions for directories and at least read, and write permissions for files (some file may be executable if (e.g.) they are scripts).
• Give the ‘group owner’ the same permissions as the ‘user’ owner, but without write permission.
• Give all ‘other’ users the same permissions as the ‘user’ owner, but without write permission.

Implementation

Initial Setup

• Make dan the owner of all of the hierarchy.

  • As any user that that can “sudo to root” (or run in a root shell without sudo):

    someuser$ sudo chown -R dan /opt/lammp/htdocs/myProject
    

• Give everyone read permission (and also execute permission for all directories and all files that already are executable by someone; any write permissions are stripped). Additionally, give dan write permission.

  • As dan (note the lack of sudo!):

    dan$ chmod -R a-st=rX,u+w /opt/lammp/htdocs/myProject
    

  This will strip the setuid/setgid/sticky bits and give directories and executables mode 755 and all other files mode 644.

Ongoing Usage

To make sure that new files are readable but not writable (by default) by others (e.g. the web server user), you should set your umask when working in this directory.

dan$ umask 022

This masks off the ‘group’ and ‘other’ write permission for new files and directories, but leaves read and execute alone.

If you forget to use this and your default umask is more restrictive (or less restrictive), then you will need to re-run the (non-sudo!) chmod command from the “Initial Setup” section. It will reset any permissions that are too strict (or too loose).