zsh compinit: insecure directories
ZshZsh CompletionZsh Problem Overview
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
Zsh Solutions
Solution 1 - Zsh
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.
Solution 2 - Zsh
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/
Solution 3 - Zsh
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.
Solution 4 - Zsh
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 ;)
Solution 5 - Zsh
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.
Solution 6 - Zsh
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)
Solution 7 - Zsh
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
Solution 8 - Zsh
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
Solution 9 - Zsh
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
Solution 10 - Zsh
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
Solution 11 - Zsh
running this command worked for me on my mac OS Catalina
:
compaudit | xargs chmod g-w,o-w
Solution 12 - Zsh
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
Solution 13 - Zsh
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.
Solution 14 - Zsh
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:
Solution 15 - Zsh
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
Solution 16 - Zsh
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/*
Solution 17 - Zsh
on Mojave, this did the trick :
sudo chmod go-w /usr/local/share
Solution 18 - Zsh
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
Solution 19 - Zsh
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
Solution 20 - Zsh
On macOS Sierra you need to run:
sudo chown -R $(whoami):staff /usr/local
Solution 21 - Zsh
-
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
Solution 22 - Zsh
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.
Solution 23 - Zsh
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.
Solution 24 - Zsh
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.
Solution 25 - Zsh
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"
Solution 26 - Zsh
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
Solution 27 - Zsh
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/
Solution 28 - Zsh
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').