In the remote server I have a post-receive hook set up in order to make a git checkout of my repository:
#!/bin/sh
GIT_WORK_TREE=/var/www/<website> git checkout -f
But when I make a push from my local machine to the git repository in the server, I get the following error messages:
remote: error: unable to unlink old '<file>' (Permission denied)
This appears many times over, one error message for almost every file.
However I have a README.txt file that I'm able to change using git, here are its permissions:
-rw-r--r-- 1 <serverusername> <serverusername> 2939 Aug 2 10:58 README.txt
But other files with exactly the same owner and same permissions, give me that error.
In another local repository for another website, I have the files with my local machine username as owner, and when I push to the remote server it respects the remote server owner of the files and works like a charm.
Obviously it seems a permissions related error, but I can't find a way to fix it, any suggestions?
When you have to unlink file, you have to have permission 'w' for directory, in which file is, not for the file...
sudo chmod -R ug+w .;
This command would fix the issue. It gives write permissions to the folder.
If you are using any IDE most likely the problem is that file was used by some process. Like your tomcat might be using the file. Try to identify that particular process and close it. That should solve your problem.
I think the problem may be with the ownership to the folder so set it to the current user ownership
sudo chown -R your_login_name /path/to/folder
sudo chown -R $USER:$USER .
Did the job for me.
I had the same issue and none of the solutions above worked for me. I deleted the offending folder. Then:
git reset --hard
Deleted any lingering files to clean up the git status, then did:
git pull
It finally worked.
NOTE: If the folder was, for instance, a public folder with build files, remember to rebuild the files
FWIW - I had a similar problem and I'm not sure if this alleviated it (beyond the permission mod): Closing Eclipse that was using the branch with this problem.
This is an old question, but this may help Mac users.
If you are copying files from Time Machine manually, instead of restoring them through Time Machine, it'll add ACLs to everything, which can mess up your permissions.
For example, the section in this article that says "How to Fix Mac OS X File Permissions" shows that "everyone" has custom permissions, which messes it all up:
https://i.stack.imgur.com/tL9Es.png
You need to remove the ACLs from those directories/files. This Super User answer goes into it, but here's the command:
sudo chmod -RN .
Then you can make sure your directories and files have the proper permissions. I use 750
for directories and 644
for files.
chflags -R nouchg /path/
, as described at: superuser.com/a/40754/199930, and found with find . -type f -flags +uchg
, as described at: coderwall.com/p/-3hwvg/find-locked-files-in-osx-terminal
git reset --hard
Worked for me
I get this error, and other strange git errors, when I have a server running (in Intellij). Stopping the server and re-trying the git command frequently fixes it for me.
Pulling may have created local change.
Add your untracked file:
git add .
Stash changes.
git stash
Drop local changes.
git stash drop
Pull with sudo permission
sudo git pull remote branch
Some files are write-protected that even git cannot over write it. Change the folder permission to allow writing e.g. sudo chmod 775 foldername
And then execute
git pull
again
Also remember to check permission of root directory itself!
You may find:
drwxr-xr-x 9 not-you www-data 4096 Aug 8 16:36 ./
-rw-r--r-- 1 you www-data 3012 Aug 8 16:36 README.txt
-rw-r--r-- 1 you www-data 3012 Aug 8 16:36 UPDATE.txt
and 'permission denied' error will pop up.
After checking the permission of the folder, it is okay with 744. I had the problem with a plugin that is installed on my WordPress site. The plugin has hooked that are in the corn job I suspected.
With a simple sudo it can fix the issue
sudo git pull origin master
You have it working.
Success story sharing
sudo chmod -R g+w
over the guilty folders.mv
actions than just overwrites.ls -l
display indicates the file type and is not related to permissions. The remaining nine characters are in three sets, each representing a class of permissions as three characters. The first set represents the user class. The second set represents the group class. The third set represents the others class. Theg+w
in chmod gives the group set (theg
parameter) permission to write (thew
parameter)