zsh compinit: insecure directories

Question

What does it mean and how can I fix it?

zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]?

Running the compaudit returns the follows:

There are insecure directories:
/usr/local/share/zsh/site-functions

If you don't have permission to change the ownership of the required folders as given in the answers, then open the `.zshrc` file and put this line at the beginning of the file `ZSH_DISABLE_COMPFIX=true`. — codeman48, Jan 02 '22 at 18:05
How is this question possibly not considered to be about "software tools primarily used by programmers"? What profession is the primary user of zsh if not programmers? — twiz, Feb 12 '23 at 11:48

chakrit · Accepted Answer · 2022-08-15T05:25:43.670

963

Note: This answer is from 2012.

This fixed it for me:

$ sudo chmod -R 755 /usr/local/share/zsh/site-functions

Credit: a post on zsh mailing list

EDIT: As pointed out by @biocyberman in the comments. You may need to update the owner of site-functions as well:

$ sudo chown -R root:root /usr/local/share/zsh/site-functions

On my machine (OSX 10.9), I do not need to do this but YMMV.

EDIT2: On OSX 10.11, only this worked:

$ sudo chmod -R 755 /usr/local/share/zsh
$ sudo chown -R root:staff /usr/local/share/zsh

Also user:staff is the correct default permission on OSX.

edited Aug 15 '22 at 05:25

answered Dec 09 '12 at 08:07

chakrit

61,017
25
133
162

3

@kirill_igum by "no root" did you mean "no root _access_"? If so, then you should copy the files to a folder you have access to, fix your `.zshenv` and `.zshrc` to use the new folder and do the same `chmod` on the new folder as I've posted with the folder. – chakrit Feb 21 '13 at 05:39
@kirill_igum see the mailing list message I've linked to. – chakrit Feb 21 '13 at 05:40
To eliminate the warning, one must make sure both permission and ownership are correct. So in addition to the chmod command here, also do: `sudo chown -R root:root ./site-functions` – biocyberman Jan 27 '14 at 19:22
@biocyberman are you on linux? I am on OSX and `ls -l ./site-functions` shows me as the owner, not root and everything seems to be ok. – chakrit Jan 28 '14 at 09:16
um ... please feel free to use the whole path instead of cd :) – Ali Afshar Mar 16 '14 at 15:26
1

I noticed that after setting the owner to root, write access needed to be revoked for both group and other. I modified the `chmod` command to `sudo chmod -R go-w zsh`. – gdvd Aug 13 '16 at 20:33
what if you are not on the sudoers file but have an account that is in the sudoers file – noɥʇʎԀʎzɐɹƆ Oct 01 '16 at 18:36
4

Note: I had symlinks in `/usr/local/share/zsh/site-functions` to `/usr/local/Cellar` and had to `chown -R root:staff /usr/local/Cellar` also before this worked. – mVChr Oct 30 '16 at 05:59
First proposal worked for me on my Ubuntu 17 distro. – Michael W. Czechowski Jun 16 '17 at 08:02
2

Didn’t clarify whether it should be `root:staff` or `user:staff` for macOS. Confusing. – Franklin Yu May 13 '19 at 21:09
1

At least on 10.15 this will break homebrew. – ManuelSchneid3r Oct 14 '20 at 10:23
1

had to use `-RL` instead of just `-R` to follow symlinks in `site-functions` – thanksd Nov 16 '20 at 13:30
second instruction in the answer helped me to fix this issue ```sudo chmod -R 755 /usr/local/share/zsh/``` – BrB Nov 27 '20 at 02:03
4

This answer did not work for me. The below answer with `compaudit` worked for me. – Vini Dec 24 '20 at 07:53
1

The last two lines did it for me on version 11.4 ```$ sudo chmod -R 755 /usr/local/share/zsh $ sudo chown -R root:staff /usr/local/share/zsh ``` – Hannibal B. Moulvad May 27 '21 at 09:40
1

EDIT2 worked for me on macOS big Sur 11.4, thanks! – Pablo Camara Sep 17 '21 at 10:25
For me I had to change the zsh permission ownership to `root:admin` because I created a second Mac login user and these were set to my first login only. It also involved navigating to the symlinks and changing the permissions in the original files. – Ian Mar 11 '22 at 19:33
These aren't even existing directories. – Kambiz Jun 17 '22 at 22:06
Guys, this post was made in **2012**. Of course it's outdated and all. I've made this post a community wiki so everyone can edit with whatever solution they find. Ultimately tho, someone from zsh or homebrew should fix this for good. – chakrit Aug 15 '22 at 05:26

score 822 · Answer 2 · edited Dec 31 '21 at 16:52

822

Removing group-write permissions with

compaudit | xargs chmod g-w

will do the trick.

See http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/

edited Dec 31 '21 at 16:52

General Grievance

4,555
31
31
45

answered Mar 31 '14 at 03:54

Wenbing Li

12,289
1
29
41

20

Far better answer, it should be noted that `compaudit` can be used to diagnose problems like these as well as fix them. – Wolph Mar 04 '15 at 10:35
26

Note that you may also have to change the owner of the files to root as well - I had to: `compaudit | xargs chown root` – Brad Parks Feb 16 '16 at 13:25
8

This is definitely the best solution for me. I installed zsh and zsh-completions with Homebrew, so obviously did not want to change it to be owned by root. – katy lavallee Oct 18 '16 at 18:10
6

`compaudit | xargs chmod g-w` together with `ompaudit | xargs chown root` worked for me too and appeared to keep HomeBrew happy. can someone explain whats going on a bit more. – nyxee Sep 05 '17 at 08:41
3

This is very similar to the solution recommended by Homebrew: https://docs.brew.sh/Shell-Completion. – Oliver Joseph Ash Nov 22 '18 at 00:04
I just did what oh-my-zsh suggested: ```compaudit | xargs chmod g-w,o-w``` Which basically sets the permissions for whatever compaudit is complaining about by removing the write permissions for group and others. – Watchmaker Aug 19 '20 at 10:54
I have `drwxr-xr-x 6 git root 4096 Aug 13 19:53 /path/to/insecure/`. `compaudit | xargs chmod g-w` will not help as `g` does not have `w` rights. What will help is `compaudit | xargs chown root` which will lead to `drwxr-xr-x 6 root root 4096 Aug 13 19:53 /path/to/insecure/`. – Timo Nov 01 '20 at 13:33
Thanks for this, was doing my nut in seeing this every time! – codeguy Aug 31 '22 at 10:14

score 266 · Answer 3 · edited May 13 '19 at 21:06

266

Most answers come with a solution, but do not mention why this warning occurs. Here's an excerpt from ZSH's compinit:

For security reasons compinit also checks if the completion system would use files not owned by root or by the current user, or files in directories that are world- or group-writable or that are not owned by root or by the current user. If such files or directories are found, compinit will ask if the completion system should really be used. To avoid these tests and make all files found be used without asking, use the option -u, and to make compinit silently ignore all insecure files and directories use the option -i. This security check is skipped entirely when the -C option is given.

Hence, the solution implies fixing one (or all) of the following:

setting the current user as the owner of all the directories/subdirectories/files in cause:
```
compaudit | xargs chown -R "$(whoami)"
```
removing write permissions for group/others for the files in cause:
```
compaudit | xargs chmod go-w
```

Another approach would be to skip these checks by using

compinit -u

but I don't really suggest this, as hiding problems under a rug only solves problems in the short run.

edited May 13 '19 at 21:06

Franklin Yu

8,920
6
43
57

answered Apr 21 '17 at 14:02

linkyndy

17,038
20
114
194

11

Thanks. I'm amazed that people would randomly type commands w/o actually understanding the problem. – shriek Jul 02 '19 at 17:38
14

What about a multi-user system? In such scenario, `chown -R "$(whoami)"` for files outside the home directory such as `/usr/local/` would not work. According to the docs, wouldn't it make more sense to make the files be root-owned? – goetz Oct 06 '19 at 14:45
2

I like this answer the best. Made me think about why this happened to me. Turns out it happened after adding another user to my user's main group. The directories under $HOME/.antigen/bundles were owned by my user and my group. So in my case removing that user from the group solved the issue. – Samuel Feb 03 '20 at 13:59
5

This is one of the top three or so answers out of dozens. Like the other few great answers, it explains what it happening and offers solutions. – David J. Jan 06 '21 at 06:43
Changing file owner and changing file privilege fails, but `compinit -u` cure all! – Neal.Marlin Apr 23 '21 at 02:58
2

This is an Excellent Answer!!! Well done thank you. This should be the best answer hands down. – James DeCarlo Jan 08 '22 at 13:17
I don't get the difference between `-u` and `-C`. Seems like they all do the same thing! – Noldorin Jan 09 '23 at 19:44

Brandt · Answer 4 · 2021-11-16T20:33:22.257

214

Once you understand the cause, solution is trivial and unequivocal.

Cause: the directories output by compaudit have write permission by either group or others (world-writable); or those files are owned by somebody else other than root or yourself.
Example: In my case, compaudit gave me that:

% compaudit 
There are insecure directories:
/usr/local/share/zsh/site-functions
/usr/local/share/zsh

And if we list the permission of those files/directories we have (in this case)

% ls -lh /usr/local/share 
total 0
drwxr-xr-x  12 chbrandt  admin   384B Aug 14 10:45 aclocal
drwxr-xr-x   8 chbrandt  admin   256B Aug 14 10:45 doc
drwxr-xr-x   3 chbrandt  admin    96B Jul 24 21:00 fish
lrwxr-xr-x   1 chbrandt  admin    36B Aug 14 10:45 gettext -> ../Cellar/gettext/0.21/share/gettext
lrwxr-xr-x   1 chbrandt  admin    41B Aug 14 10:45 gettext-0.21 -> ../Cellar/gettext/0.21/share/gettext-0.21
lrwxr-xr-x   1 chbrandt  admin    37B Aug 14 10:45 gtk-doc -> ../Cellar/libidn2/2.3.0/share/gtk-doc
drwxr-xr-x   9 chbrandt  admin   288B Aug 14 10:45 info
drwxr-xr-x  58 chbrandt  admin   1.8K Aug 14 10:45 locale
lrwxr-xr-x   1 chbrandt  admin    41B Jul 27 17:12 luajit-2.0.5 -> ../Cellar/luajit/2.0.5/share/luajit-2.0.5
drwxr-xr-x   5 chbrandt  admin   160B Jul 27 17:12 man
lrwxr-xr-x   1 chbrandt  admin    33B Aug 14 10:45 nvim -> ../Cellar/neovim/0.4.4/share/nvim
drwxrwxr-x   3 chbrandt  admin    96B Jul 24 20:57 zsh
%
% ls -lh /usr/local/share/zsh 
total 0
drwxrwxr-x  4 chbrandt  admin   128B Jul 24 21:00 site-functions
%
% ls -lh /usr/local/share/zsh/site-functions 
total 0
lrwxr-xr-x  1 chbrandt  admin    39B Jul 24 21:00 _brew -> ../../../Homebrew/completions/zsh/_brew
lrwxr-xr-x  1 chbrandt  admin    44B Jul 24 21:00 _brew_cask -> ../../../Homebrew/completions/zsh/_brew_cask

Now we easily spot the issue, don't we? Notice how zsh/ and zsh/site-functions directories differ from the others... That 'w' allowing the admin group to modify them is not appreciated by zsh.

Solution: Turn off that group-writable permission!

% chmod g-w /usr/local/share/zsh 
% chmod g-w /usr/local/share/zsh/site-functions

That's it! You're good to go. Open a new terminal and you should not see the "zsh compinit: insecure directories" message anymore ;)

edited Nov 16 '21 at 20:33

answered Aug 17 '20 at 09:05

Brandt

5,058
3
28
46

1

What would generally cause these permissions to change for these directories? – Jaap Wijnen Feb 20 '21 at 20:43
2

@JaapWijnen I don't think they were _changed_, those directories were probably _created_ like that. I don't even consider that an error (if you think through the whole environment and `chbrandt` being a "su" and `admin` being a previledged group so on and so forth...). In this case in particular -- now answering your question -- those "wrong" permissions are/were probably the result of a tiny bug in the realm of zsh/homebrew...or a misunderstood feature ;) – Brandt Feb 22 '21 at 13:57
@Brandt I think so too. My conclusion is to disable the compinit security check as changing ownership/permissions currently breaks homebrew. – Marcel Boldt Jul 04 '21 at 16:59
4

This is the best answer, because it explains the problem, and shows a real concrete example while applying the solution – Alessio Jul 15 '21 at 10:55
1

@Brandt I tried to apply your suggested changes but the error remains, I posted a separte question https://apple.stackexchange.com/questions/431861/zsh-compinit-errors?noredirect=1#comment618960_431861 – Koenig Lear Dec 03 '21 at 15:25
2

Excellent. This resolved my issue I was having when trying to enable aws cli command completion in zsh. If you want a one liner, here it is `compaudit | sed -n '2,$ p' | xargs -I{} chmod g-w {}` – GMaster Feb 26 '22 at 01:21
Applied solution then ran `compaudit`, same directories still show as insecure – Farid Jul 05 '22 at 05:09
@Farid Interesting. Can you confirm those files/directories' permissions, please? They should be read-only (`chmod go-w`) to everybody but _you_ and `root` (according to the docs). – Brandt Jul 05 '22 at 13:23
@Brandt I used this answer (https://stackoverflow.com/a/63172694/5636313) and it worked – Farid Jul 05 '22 at 13:33
@Farid It means that the file(s) was/were being owned by somebody else other than you or root. Apparently you didn't pay attention to that, which is what my answer hopes to share. – Brandt Jul 05 '22 at 15:40

Hank Chan · Answer 5 · 2020-12-05T09:20:01.360

58

This works for my Mac since High Sierra update.

Remove the group write access:

sudo chmod g-w /usr/local/share/zsh/site-functions
sudo chmod g-w /usr/local/share/zsh

It’s best to keep the change limited to zsh directories.

edited Dec 05 '20 at 09:20

answered Mar 26 '18 at 13:23

Hank Chan

1,706
1
16
21

6

This was the only fix that worked for me on Mac Catalina – user8467470 Jun 18 '20 at 11:10
1

Directories are still listed as insecure – Farid Jul 05 '22 at 05:10

score 46 · Answer 6 · edited Feb 23 '21 at 17:50

46

This answer is mostly a reference for myself to use in the future, as most answers do not provide a full-fledged solution. Here it is:

First run:

compinit

use compaudit if above does not work

For every single path that is printed run the following the commands:

sudo chown $(whoami) PATH_HERE

sudo chmod -R 755 PATH_HERE

Simple example, let's say one of the paths that gets printed after running compinit is "/usr/local/share/zsh". Then:

sudo chown $(whoami) /usr/local/share/zsh

sudo chmod -R 755 /usr/local/share/zsh

edited Feb 23 '21 at 17:50

Farrukh Taqveem Haider

123
2
5

answered Jul 30 '20 at 11:59

Berat Cevik

1,818
3
22
28

3

Just running `sudo chown $(whoami) PATH_HERE` worked for me. Thanks! – R Sun Jun 26 '21 at 18:34
3

This answer was the good one in my case. – Yohan W. Dunon Mar 04 '22 at 08:56
2

This was the only one that actually worked for me. Thank you – Chaos Monkey Jun 07 '22 at 12:46
1

Weird, that is only solution that worked for me – Farid Jul 05 '22 at 05:12
1

Only one that worked for me -- OSX Monterey 12.5.1 – Michael Paler Oct 13 '22 at 13:43

score 42 · Answer 7 · answered Mar 02 '21 at 01:45

42

This command updates all files/folders with correct permissions:

compaudit | xargs chmod g-w

You don't need to use sudo to change the owner - unless the file belongs to root

(Tested on macOS BigSur)

answered Mar 02 '21 at 01:45

wlads

767
7
9

1

This should be the correct answer. While using "sudo" you must be cautious. – Vaibhav Sidapara Jan 19 '22 at 15:01
Nothing changed, `compaudit` still lists insecure directories – Farid Jul 05 '22 at 05:11

score 31 · Answer 8 · answered Oct 26 '13 at 01:28

31

I got the same warnings when I sudo -i starting a root shell, @chakrit's solution didn't work for me.

But I found -u switch of compinit works, e.g. in your .zshrc/zshenv or where you called compinit

compinit -u

NB: Not recommended for production system

See also http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization

answered Oct 26 '13 at 01:28

number5

15,913
3
54
51

that was the only soution that worked for me. i was trying to use zsh with compinit on linux subsystem on windows 10 – denns Sep 01 '17 at 15:40
i tried all the other solutions and then this and its the only thing that worked for me. thank you, – danfromisrael Sep 09 '22 at 05:59

Sebastien H. · Answer 9 · 2022-06-14T15:32:13.403

25

on Mojave, this did the trick : sudo chmod go-w /usr/local/share

[Update 2022]

If using ZSH Completions, you should use chmod -R go-w "$(brew --prefix)/share"

edited Jun 14 '22 at 15:32

answered Mar 08 '19 at 11:24

Sebastien H.

6,818
2
28
36

4

Better still: `sudo chmod -R go-w /usr/local/share` – ecmanaut Apr 29 '20 at 21:27
1

`/usr/local/share/zsh` is enough. – greatvovan Dec 08 '20 at 21:44
2

If using zsh completions: https://docs.brew.sh/Shell-Completion#configuring-completions-in-zsh says to `chmod -R go-w "$(brew --prefix)/share"` – dijonkitchen Jun 03 '22 at 08:55

score 24 · Answer 10 · answered May 11 '20 at 06:43

24

I had the same warning lately on Catalina. An easy workaround is to put this to the top of your .zshrc

ZSH_DISABLE_COMPFIX=true

answered May 11 '20 at 06:43

FredericK

1,612
1
18
26

2

This is the only solution that helped me on macOS Catalina 10.15.5! All the other things like `compaudit | xargs chmod go-w` or `compinit -u` doesn't seem to be work on this version of macOS – Denis L Jul 15 '20 at 19:03
1

Only solution that worked on macOS BigSur 11.2.1 (20D74). Thanks a lot. – Ahmet Ardal Feb 18 '21 at 12:05
1

Best solution so far. Since I use separate account on my MacBook for multiple clients and personal use, I have multiple users using the zsh folders and I don't want to switch ownership all the time. Adding this environment variable got rid of the annoying message at least. – Joost den Boer May 10 '22 at 07:02
1

Yup this is all that worked for me on Catalina too. Typical example of Apple's recent updates to their OS over the years just breaking more and more things and adding so many privacy and security checks that it's made OS X a totally unwelcome OS for any kind of development. – pilcrowpipe Jul 15 '22 at 22:17

score 17 · Answer 11 · answered Dec 02 '16 at 16:01

17

The accepted answer did not work for me on macOs Sierra (10.12.1). Had to do it recursive from /usr/local

cd /usr/local
sudo chown -R <your-username>:<your-group-name> *

Note: You can get your username with whoami and your group with id -g

answered Dec 02 '16 at 16:01

Franco

848
1
12
24

7

I had t do it this way as well on Sierra, though on a multiuser system the correct user/group should be root:staff – Marshall Eubanks Jun 25 '17 at 18:35

score 15 · Answer 12 · answered May 12 '20 at 20:12

15

running this command worked for me on my mac OS Catalina:

compaudit | xargs chmod g-w,o-w

answered May 12 '20 at 20:12

Miguel Julio

151
1
2

1

having only this compaudit | xargs chmod g-w worked for me. – Jawadh Salih Rifath Oct 07 '20 at 03:43

score 13 · Answer 13 · edited May 19 '20 at 14:39

13

My machine:

System Version: macOS 10.15.4 (19E287)
Kernel Version: Darwin 19.4.0

So here is what I did,

run compaudit and it will give you a list of directories it thinks are unsecure.
run sudo chmod -R 755 target_directory (example: sudo chmod -R 755 /usr/local/share/zsh)

Exmaple:

compaudit

returns:

/usr/local/share/zsh

so I run

sudo chmod -R 755 /usr/local/share/zsh

read more here link

edited May 19 '20 at 14:39

Peyman Mohamadpour

17,954
24
89
100

answered May 19 '20 at 13:37

sultanmyrza

4,551
1
30
24

1

This worked perfectly for me on Big Sur – diek Oct 28 '21 at 18:33

score 13 · Answer 14 · answered Jun 05 '20 at 22:18

13

MAC OS X solution :

$ sudo chmod -R 755 /usr/local/share/zsh
$ sudo chown -R root:staff /usr/local/share/zsh

Also "user:staff = default root user on OSX.

answered Jun 05 '20 at 22:18

jpmottin

2,717
28
25

score 13 · Answer 15 · answered Apr 29 '21 at 08:26

I was getting this issue for the past may months tried few things but didn't worked. Finally what helped me was this. Get the list of insecure directories and then set the chmod of all of them as described below.

CLI# compaudit
There are insecure directories:
/usr/local/share/zsh
CLI# sudo chmod -R 755 /usr/local/share/zsh
Password:

score 12 · Answer 16 · edited Jun 22 '21 at 04:31

12

I fixed it by doing

sudo chown -R root:staff /usr/local/share/zsh

in my case other directories inside share/ also have "staff" group assigned

edited Jun 22 '21 at 04:31

richy2509

3
2

answered Jan 08 '18 at 15:33

Franck Mercado

169
1
5

score 11 · Answer 17 · answered Dec 11 '21 at 15:33

I tried every solution posted, in the end none of them worked for my particular case. However, I want to extend my gratitude to the users who pointed me in the direction of the ownership being the real issue regarding multiple accounts, not the mode. I'm posting this answer for anyone else with a similar setup (M1 + two accounts + /opt/homebrew/share).

Here is my setup:

I have an M1, running macOS Monterey 12.0.1, using Homebrew.

I have two accounts, one admin and one regular user (required split for work). I only had the insecure directories issue on the regular user, both users use the same homebrew setup, with the following directories and files being affected by the issue:

/opt/homebrew/completions/zsh/_brew
/opt/homebrew/share/zsh
/opt/homebrew/share/zsh/site-functions
/opt/homebrew/share/zsh/site-functions/_brew
/opt/homebrew/share/zsh/site-functions/_brew_services
/opt/homebrew/share/zsh/site-functions/_cargo
/opt/homebrew/share/zsh/site-functions/_gh
/opt/homebrew/share/zsh/site-functions/_git
/opt/homebrew/share/zsh/site-functions/_j
/opt/homebrew/share/zsh/site-functions/_lf
/opt/homebrew/share/zsh/site-functions/_task
/opt/homebrew/share/zsh/site-functions/_tldr
/opt/homebrew/share/zsh/site-functions/_vifm

Changing the mode did nothing, in the end what fixed the issues was changing the ownership of every problem file and dir to root:admin, like so:

sudo chown root:admin /opt/homebrew/share/zsh/site-functions/*

Originally, before the issue presented itself, my admin user owned everything, ownership therefore looked like this: usr:admin

This is what the site-functions dir looks like now, no issues:

lrwxr-xr-x  1 root admin  30 Jul 19 19:41 _brew ->../../../completions/zsh/_brew
lrwxr-xr-x  1 root admin  79 Aug 10 20:26 _brew_services -> ../../../Library/Taps/homebrew/homebrew-services/completions/zsh/_brew_services
lrwxr-xr-x  1 root admin  59 Nov  6 16:28 _cargo -> ../../../Cellar/rust/1.56.1/share/zsh/site-functions/_cargo
lrwxr-xr-x  1 root admin  53 Dec  2 23:37 _gh -> ../../../Cellar/gh/2.3.0/share/zsh/site-functions/_gh
lrwxr-xr-x  1 root admin  56 Nov 30 15:21 _git -> ../../../Cellar/git/2.34.1/share/zsh/site-functions/_git
lrwxr-xr-x  1 root admin  61 Oct 13 11:12 _j -> ../../../Cellar/autojump/22.5.3_3/share/zsh/site-functions/_j
lrwxr-xr-x  1 root admin  50 Oct 23 18:52 _lf -> ../../../Cellar/lf/26/share/zsh/site-functions/_lf
lrwxr-xr-x  1 root admin  57 Nov  6 16:28 _task -> ../../../Cellar/task/2.6.1/share/zsh/site-functions/_task
lrwxr-xr-x  1 root admin  57 Nov 18 01:45 _tldr -> ../../../Cellar/tldr/1.4.2/share/zsh/site-functions/_tldr
lrwxr-xr-x  1 root admin  56 Oct 13 11:11 _vifm -> ../../../Cellar/vifm/0.12/share/zsh/site-functions/_vifm

This was my issue as well. Thank you! – Deimyts Aug 23 '23 at 22:32 — Deimyts, Aug 23 '23 at 22:32

score 9 · Answer 18 · answered Jan 16 '17 at 11:03

9

These two lines have fixed for me.

sudo chown -R _user_:root /usr/local/share/zsh

sudo chown -R _user_:root /usr/local/share/zsh/*

answered Jan 16 '17 at 11:03

arglee

1,374
4
17
30

3

Work for me! I use a network account on my PC - Ubutun 16.04 `sudo chown -R $(whoami):root /usr/local/share/zsh` `sudo chown -R $(whoami):root /usr/local/share/zsh/*` – hoangdv Dec 15 '17 at 03:33
...and if you have symlinks that point to somewhere else, you need to chown those too – Sridhar Sarnobat Jun 30 '21 at 00:50

score 8 · Answer 19 · answered Feb 01 '21 at 20:26

8

Following worked on M1

ProductName:    macOS
ProductVersion: 11.1
BuildVersion:   20C69

% compaudit
/opt/homebrew/share

Changed group permission from 775 to 755

% sudo chmod 755 /opt/homebrew/share

drwxr-xr-x   33 xenea  admin   1056 Feb  2 01:28 share

answered Feb 01 '21 at 20:26

ras

618
8
15

also worked on non-M1 MBP 2019 running OS 11.2 – David Schumann Feb 08 '21 at 23:14

score 7 · Answer 20 · answered Dec 15 '19 at 06:40

7

run compaudit and it will give you a list of directories it thinks are insecure
sudo chown -R username:root target_directory
sudo chmod -R 755 target_directory

answered Dec 15 '19 at 06:40

Sharif Mohammad Eunus

826
8
14

score 7 · Answer 21 · answered Apr 03 '20 at 12:11

This was the only thing that worked for me from https://github.com/zsh-users/zsh-completions/issues/433#issuecomment-600582607. Thanks https://github.com/malaquiasdev!

  $ cd /usr/local/share/
  $ sudo chmod -R 755 zsh
  $ sudo chown -R root:staff zsh

score 5 · Answer 22 · answered Apr 26 '17 at 11:05

5

On macOS Sierra you need to run: sudo chown -R $(whoami):staff /usr/local

answered Apr 26 '17 at 11:05

kkodev

2,557
23
23

score 5 · Answer 23 · answered Mar 16 '20 at 21:14

5

My suggestion would be to run compaudit and then just fix permissions on the directories found by the audit. Make sure the identified directories do not have write permissions for group or other.

answered Mar 16 '20 at 21:14

Tiamot

61
1
4

score 4 · Answer 24 · answered Mar 19 '21 at 16:34

I don't see any answer that references the homebrew information on this topic: https://docs.brew.sh/Shell-Completion#configuring-completions-in-zsh

To make Homebrew’s completions available in zsh, you must get the Homebrew-managed zsh site-functions on your FPATH before initialising zsh’s completion facility. Add the following to your ~/.zshrc file:

if type brew &>/dev/null; then
  FPATH=$(brew --prefix)/share/zsh/site-functions:$FPATH

  autoload -Uz compinit
  compinit
fi

This must be done before compinit is called.

This solved the problem for me without manually changing ownership or otherwise.

score 3 · Answer 25 · answered Oct 15 '19 at 18:38

This morning, some packages in my system updated, and left me with this error message. I am using Ubuntu 18.04.

Apparently, something in the update changed the username and group to numbers, instead of root, as so:

# There are insecure files: /usr/share/zsh/vendor-completions/_code
# sudo ls -alh
-rw-r--r-- 1  131  142 2.6K 2019-10-10 16:28 _code

I simply changed the user and group for this file back to root and the problem went away. I did not need to change any permissions, and would caution against doing so unless the underlying cause of the problem is understood.

sudo chown root _code && sudo chgrp root _code

After switching 131 and 142 back to root, this error message from zsh went away.

Alf Eaton · Answer 26 · 2020-11-23T10:21:06.443

3

I got this issue after running the google-cloud-sdk install script, which adds command-completion to the shell via an entry in .zshrc.

Following Homebrew's instructions for configuring completions in zsh was helpful.

Additionally, if you receive “zsh compinit: insecure directories” warnings when attempting to load these completions, you may need to run this: chmod -R go-w "$(brew --prefix)/share"

edited Nov 23 '20 at 10:21

answered Jun 11 '20 at 11:38

Alf Eaton

5,226
4
45
50

score 2 · Answer 27 · answered Nov 07 '19 at 16:32

2

None of the solutions listed worked for me. Instead, I ended up uninstalling and reinstalling Homebrew, which did the trick. Uninstall instructions may be found here: http://osxdaily.com/2018/08/12/how-uninstall-homebrew-mac/

answered Nov 07 '19 at 16:32

Wes

1,720
3
15
26

score 2 · Answer 28 · answered Dec 12 '20 at 17:42

Send a y character to the input stream of the script using compinit, in order to automatically answer the Ignore insecure directories and files and continue [y] or abort compinit [n]? question

echo "y" > source <GOOGLECLOUDSDK>/completion.zsh.inc

The solution is useful when

you can't make ownership/access changes to the folders
when you can't use the -u option to remove the warning (probably because you don't explicitly call 'compinit' yourself, but it's called by a script you call)

Remark: It doesn't fix the problem and only hides the warning (as opposed to others answers here which involve removing 'group write access' or 'change ownership to root').

zsh compinit: insecure directories

28 Answers28

read more here link

Linked