zsh compinit: insecure directories, run compaudit for list
When I try to login as root, this warning comes up.
luvpreet@DHARI-Inspiron-3542:/$ sudo su Password: zsh compinit: insecure directories, run compaudit for list. Ignore insecure directories and continue [y] or abort compinit [n]?
If I say yes, it simply logs in, and my shell changes from bash to zsh.
If I say no, it says that
ncompinit: initialization aborted and logs in.
After login, my shell changes to zsh.
All I ever did related to zsh, was download oh-my-zsh from github.
What is happening and why ?
Using – Ubuntu 16.04 on Dell.
I encountered the same problem after following https://docs.npmjs.com/getting-started/fixing-npm-permissions, and I solved it using:
% cd /usr/local/share/zsh % sudo chmod -R 755 ./site-functions % sudo chown -R root:root ./site-functions
I found the answer here: https://stackoverflow.com/questions/13762280/zsh-compinit-insecure-directories
When I would run
compaudit, I would get the insecure directories error from the plugins directory of
oh-my-zsh. So I changed the permissions in the plugins directory:
sudo chmod -R 755 ./plugins
fixed the issue for me.
Ubuntu 16.0.4 on WSL.
I’m using WSL and the above solutions didn’t fix it for me, but they did lead me towards this incantation which did fix it:
cd ~ compaudit | xargs chown -R "$(whoami)" compaudit | xargs chmod -R go-w
This morning, some packages in my system updated, and left me with this error message.
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
142 back to
root, this error message from zsh went away.
There are multiple solutions on how to fix the problem in this question. However I stumbled upon this thread due to an issue with antigen bundle installs on Windows 10 Ubuntu WSL. I solved it by setting the umask 022 within my .zshrc to ensure that new directories are created with the correct umask.
compaudit | xargs chmod g-w nor
ZSH_DISABLE_COMPFIX=true worked for me when trying to solve this issue for a non-sudo user on macOS.
What did help was to use
From the docs here: https://zsh.sourceforge.io/Doc/Release/Completion-System.html
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, provided the dumpfile exists.
The odd thing for me was that the files did fulfill the requirements (owned by root and not group writable) but I still kept getting the error. Using
-u solved that.