zsh compinit: insecure directories [closed]

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

Roborant

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. – Pneumonia

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? – Millenary

Tried all comments. Only this command fixed it: sudo chown -R $(whoami):admin /usr/local/* – Negrophobe

Answer 1

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, where user is actually your username (i.e. whoami, or $USER). In other words:

$ sudo chown -R ${USER}:staff /usr/local/share/zsh

Compony

@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. – Compony

@kirill_igum see the mailing list message I've linked to. – Compony

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 – Joacimah

@Joacimah 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. – Compony

um ... please feel free to use the whole path instead of cd :) – Dallon

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. – Mink

what if you are not on the sudoers file but have an account that is in the sudoers file – Originate

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. – Entoil

First proposal worked for me on my Ubuntu 17 distro. – Tubulure

Didn’t clarify whether it should be root:staff or user:staff for macOS. Confusing. – Felske

At least on 10.15 this will break homebrew. – Divulge

had to use -RL instead of just -R to follow symlinks in site-functions – Materialist

second instruction in the answer helped me to fix this issue sudo chmod -R 755 /usr/local/share/zsh/ – Concepcion

This answer did not work for me. The below answer with compaudit worked for me. – Clupeid

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 – Rumormonger

EDIT2 worked for me on macOS big Sur 11.4, thanks! – Marhtamari

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. – Byzantine

These aren't even existing directories. – Krenn

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. – Compony

Answer 2

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/

Readymix

Far better answer, it should be noted that compaudit can be used to diagnose problems like these as well as fix them. – Frenchify

Note that you may also have to change the owner of the files to root as well - I had to: compaudit | xargs chown root – Anisotropic

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. – Glade

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. – Wrestle

This is very similar to the solution recommended by Homebrew: docs.brew.sh/Shell-Completion. – Berwick

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. – Pentstemon

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/. – Rexanna

This would be a better answer if the 'why' explanation was included in the answer rather than simply linked. – Couperin

Answer 3

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.

Omora

Thanks. I'm amazed that people would randomly type commands w/o actually understanding the problem. – Finale

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? – Dagny

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. – Condyle

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. – Sheff

Changing file owner and changing file privilege fails, but compinit -u cure all! – Leventhal

This is an Excellent Answer!!! Well done thank you. This should be the best answer hands down. – Flake

I don't get the difference between -u and -C. Seems like they all do the same thing! – Yolandoyolane

Answer 4

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 ;)

Jansenism

What would generally cause these permissions to change for these directories? – Representation

@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 ;) – Jansenism

@Jansenism I think so too. My conclusion is to disable the compinit security check as changing ownership/permissions currently breaks homebrew. – Blocky

This is the best answer, because it explains the problem, and shows a real concrete example while applying the solution – Burr

@Jansenism I tried to apply your suggested changes but the error remains, I posted a separte question apple.stackexchange.com/questions/431861/… – Lentissimo

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 {} – Boson

Applied solution then ran compaudit, same directories still show as insecure – Nonconformance

@Nonconformance 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). – Jansenism

@Jansenism I used this answer (https://mcmap.net/q/53898/-zsh-compinit-insecure-directories-closed) and it worked – Nonconformance

@Nonconformance 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. – Jansenism

Answer 5

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.

Bracknell

This was the only fix that worked for me on Mac Catalina – Cameraman

Directories are still listed as insecure – Nonconformance

Answer 6

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

Michal

Just running sudo chown $(whoami) PATH_HERE worked for me. Thanks! – Loiretcher

This answer was the good one in my case. – Wilbourn

This was the only one that actually worked for me. Thank you – Surrey

Weird, that is only solution that worked for me – Nonconformance

Only one that worked for me -- OSX Monterey 12.5.1 – Vespertilionine

Answer 7

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)

Homestead

This should be the correct answer. While using "sudo" you must be cautious. – Succubus

Nothing changed, compaudit still lists insecure directories – Nonconformance

Answer 8

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

Csc

that was the only soution that worked for me. i was trying to use zsh with compinit on linux subsystem on windows 10 – Aldehyde

i tried all the other solutions and then this and its the only thing that worked for me. thank you, – Batish

Answer 9

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

[Update 2022]

If using ZSH Completions installed through Homebrew, you should use:

chmod -R go-w "$(brew --prefix)/share"

As noted in the documentation: https://docs.brew.sh/Shell-Completion#configuring-completions-in-zsh

Stephenstephenie

Better still: sudo chmod -R go-w /usr/local/share – Acred

/usr/local/share/zsh is enough. – Fra

If using zsh completions: docs.brew.sh/Shell-Completion#configuring-completions-in-zsh says to chmod -R go-w "$(brew --prefix)/share" – Grot

Answer 10

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

Profiteer

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 – Muldon

Only solution that worked on macOS BigSur 11.2.1 (20D74). Thanks a lot. – Magocsi

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. – Bollinger

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. – Junna

Answer 11

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

Fail

I had t do it this way as well on Sierra, though on a multiuser system the correct user/group should be root:staff – Eboh

Answer 12

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

compaudit | xargs chmod g-w,o-w

Roxannroxanna

having only this compaudit | xargs chmod g-w worked for me. – Nevernever

Answer 13

My machine:

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

So here is what I did,

1. run compaudit and it will give you a list of directories it thinks are unsecure.

2. 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

Miyamoto

This worked perfectly for me on Big Sur – Jamila

Answer 14

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.

Gayton

Answer 15

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:

Merrill

Answer 16

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

Blackdamp

Answer 17

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

Lozoya

This was my issue as well. Thank you! – Monadism

Answer 18

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

Jeuz

also worked on non-M1 MBP 2019 running OS 11.2 – Illstarred

Answer 19

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/*

Lyda

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/* – Bedelia

...and if you have symlinks that point to somewhere else, you need to chown those too – Photolithography

Answer 20

1. run compaudit and it will give you a list of directories it thinks are insecure

2. sudo chown -R username:root target_directory

3. sudo chmod -R 755 target_directory

Catullus

Answer 21

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

Alon

Answer 22

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

Lessee

Answer 23

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.

Hermaphroditism

Answer 24

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.

Dalenedalenna

Answer 25

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.

Handball

Answer 26

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"

Classless

Answer 27

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/

Bandurria

Answer 28

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').

Cortezcortical