Home/ Questions/Q 7990723
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T13:05:55+00:00

When I pull files down on OSX with terminal, I don’t have edit permissions

  • 0

When I pull files down on OSX with terminal, I don’t have edit permissions by default.
How can I change that?

kirkstrobeck:atheycreek kirkstrobeck$ ls -lad ~ . .git
drwxrwxrwx   8 kirkstrobeck  staff   272 May 24 18:20 .
drwxrwxrwx  16 kirkstrobeck  staff   544 May 25 10:58 .git
drwxr-xr-x+ 92 kirkstrobeck  staff  3128 May 24 15:17 /Users/kirkstrobeck

kirkstrobeck:~ kirkstrobeck$ umask
0022

kirkstrobeck:atheycreek kirkstrobeck$ ls -l
total 8
-rwxrwxrwx  1 kirkstrobeck  staff  2143 Mar  6 14:49 README.md
drwxrwxrwx  4 kirkstrobeck  staff   136 May 23 14:45 www
kirkstrobeck:atheycreek kirkstrobeck$

Note: I ran these terminal commands after fixing the issue with CHMOD, but I do that every time, because it pulls down the wrong perms.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    When you say you don’t have edit permissions – what exactly do you mean?

    Note: I ran these terminal commands after fixing the issue with CHMOD

    That means the output isn’t helpful. All these permissions show:

    kirkstrobeck:atheycreek kirkstrobeck$ ls -lad ~ . .git
drwxrwxrwx   8 kirkstrobeck  staff   272 May 24 18:20 .
drwxrwxrwx  16 kirkstrobeck  staff   544 May 25 10:58 .git
drwxr-xr-x+ 92 kirkstrobeck  staff  3128 May 24 15:17 /Users/kirkstrobeck

    is that you do have edit permissions for everything listed – to be expected if you’ve previously ran chmod -R 777 . on the folder.

    The more relevant permissions are those of the file and folder for the things you’re trying to edit. With a specific example of a command, the errors it generated and the permissions of relevant files – would come a specific answer, in the absence of that, some educated guess work:

    Write perms aren’t a git problem

    Git doesn’t store folders at all, and only stores the executable permission for files. you can demonstrate this to yourself with something like this:

    [andy@work:/tmp/so/original]$ git init
[andy@work:/tmp/so/original]$ touch 0700
[andy@work:/tmp/so/original]$ touch 0600
[andy@work:/tmp/so/original]$ touch 0500
[andy@work:/tmp/so/original]$ touch 0400
[andy@work:/tmp/so/original]$ chmod 0700 0700
[andy@work:/tmp/so/original]$ chmod 0600 0600
[andy@work:/tmp/so/original]$ chmod 0500 0500
[andy@work:/tmp/so/original]$ chmod 0400 0400
[andy@work:/tmp/so/original]$ git add *
[andy@work:/tmp/so/original]$ git commit -va
[master (root-commit) a304e1b] adding files with the named permissions
0 files changed
create mode 100644 0400
create mode 100755 0500
create mode 100644 0600
create mode 100755 0700
[andy@work:/tmp/so/original(master)]$ ls -la 
total 12
drwxr-xr-x 3 andy users 4096 May 28 14:51 .
drwxr-xr-x 3 andy users 4096 May 28 14:48 ..
-r-------- 1 andy users    0 May 28 14:48 0400
-r-x------ 1 andy users    0 May 28 14:48 0500
-rw------- 1 andy users    0 May 28 14:48 0600
-rwx------ 1 andy users    0 May 28 14:48 0700
drwxr-xr-x 8 andy users 4096 May 28 14:51 .git

    The above shows (with ls -la) file permissions indicated as both numbers (the filenames) and read, write, executable perms (on the left). Only the two files 0500 and 0700 have executable permissions.

    [andy@work:/tmp/so/checkout]$ git init
Initialized empty Git repository in /tmp/so/checkout/.git/
[andy@work:/tmp/so/checkout]$ git pull ../original/
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../original
* branch            HEAD       -> FETCH_HEAD
[andy@work:/tmp/so/checkout(master)]$ ls -la 
total 12
drwxr-xr-x 3 andy users 4096 May 28 14:52 .
drwxr-xr-x 4 andy users 4096 May 28 14:52 ..
-rw-r--r-- 1 andy users    0 May 28 14:52 0400
-rwxr-xr-x 1 andy users    0 May 28 14:52 0500
-rw-r--r-- 1 andy users    0 May 28 14:52 0600
-rwxr-xr-x 1 andy users    0 May 28 14:52 0700
drwxr-xr-x 8 andy users 4096 May 28 14:52 .git
[andy@work:/tmp/so/checkout(master)]$

    The above indicates that the checkout has default file permissions (those dictated by umask) with the addition of being executable if committed as executable.

    Knowing the above should help you focus on where the real problem lies.

    Fixing file permissions

    If your checkout has wrong permissions, you can fix them with a command like this:

    # make sure all files are owned by you
sudo chmod -R andy:users .
# reset to default permissions
sudo find . -type d -exec chmod 0755 {} \; -or -type f -exec chmod 0644 {} \;

    Double check that for files mentioned in whatever error message you have; the permissions of the file are now 0644, and the folder it’s in are 0755.

    With file permissions corrected, you should be good to go.

    Note that you need executable permissions on folders to be able to find and manipulate the contents. If you don’t have executable perms on a folder you’ll get permission errors doing almost anything within it. But, again, git doesn’t store folders at all, it’s not git-related if that’s the problem.

    If that made any changes to your repo you can commit them with:

    git commit -am "Resetting file permissions to their default values"

    That’ll only be committing changes to the executable property of files, and is just a cleanup step – not fixing anything which would cause permission issues to someone else checking out the repo.

    Ignoring file permissions

    If you want your checkout to entirely ignore permissions you apply to your checkout, you can use:

    git config core.fileMode false

    in this way git won’t consider file-permission changes you apply to your checkout as changes to commit – but that’s not likely to be relevant given the information available.

    • 0