Can't use Watchman: "Operation not permitted" - watchman

Since updating Watchman recently (with Homebrew) I can no longer use it to watch projects. I get
{
"version": "2022.05.30.00",
"error": "std::__1::system_error: open: /Users/Path/To/Project: Operation not permitted"
}
I initially assumed that this must simply be file access issue I could resolve in the normal way, but giving the watchman app access to Files & Folders does not resolve the issue (even with termination of all watchman processes and restart of Terminal).
For good measure, I also manually added the watchman executable to Full Disk Access (something I've never needed to do before and am not comfortable with) but this also had no effect.
I have also terminated every relevant process I can think of, and even rebooted, twice. As far as I know the only change since Watchman worked was my running brew update watchman (which I have of course also uninstalled and reinstalled).
One concern is that for some reason I have multiple entries for watchmen in System Preferences, which weirdly results in it taking several dozen attempts to whack-a-mole all of them into a checked state for access:
How do I give Watchman the permissions needs to overcome this error?

Update Aug-19-2022
It looks like watchman: stable 2022.08.15.00 is working fine on my Mac M1. Upon start, you need to grant access to the local folders about to be synched.
Original
I also had the problem, like many others.
I reverted to a "working" version, e.g. 2022.05.16.00
There are multiple ways to do so; one (without private taps) would be:
Uninstall watchman
Downgrade the watchman.rb formula to an older version
https://github.com/Homebrew/homebrew-core/find/master
Navigate to watchman.rb
History -> select needed version -> View file -> Raw
Copy link to raw data
replace formula with that from raw version link
Install watchman according to that version
Pin it (to prevent further watchman updates)
Finally reset the watchman.rb formula to the original state again
# -- 1 -- uninstall
brew uninstall watchman
# -- 2 -- replace formula
curl https://raw.githubusercontent.com/Homebrew/homebrew-core/8651d8e23d308e564414188509f864e40548f514/Formula/watchman.rb > /opt/homebrew/Library/Taps/homebrew/homebrew-core/Formula/watchman.rb
# -- 3 -- install again, using replaced formula
brew install watchman
# -- 4 -- pin that version - Don't forget to unpin once this problem is solved...
brew pin watchman
# -- 5 -- reset formula to original
cd /opt/homebrew/Library/Taps/homebrew/homebrew-core/Formula/
git checkout -- watchman.rb
Then shutdown any lingering instances of Watchman with
watchman shutdown-server
Remark: On Intel-Macs, homebrews repository is located at a different place. You can find out by calling brew --repository.
Typically, the Formula is expected in directory /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula
Once the problems with watchman are solved, you can unpin watchman again and use the normal brew update/upgrade machanism.

On my M1 Mac:
My issue was that watchman didn't have permissions to ~/Documents folder. I don't know if this was the case before or after reinstalled it. Here are the steps I took:
brew uninstall watchman
brew install watchman
watchman shutdown-server (just in case it's running)
watchman watch-del-all
yarn start --reset-cache
When I tried to launch metro, MacOS prompted me to give permissions. After accepting, the bundler ran without issue.

It seems that the problem is that the watchman didn't have permission to access the ~/Documents folder. 🤔 Reinstalling watchmen seems to work as it triggers the grant access prompt.

Related

Linking postgresql in homebrew

I already installed postgresql, but it says I did not link to it.
I am running this in the command line and getting the following error:
myname#MacBook-Pro-8 ~> brew install postgresql
Warning: postgresql 10.4 is already installed, it's just not linked
You can use `brew link postgresql` to link this version.
myname#MacBook-Pro-8 ~> brew link postgresql
Linking /usr/local/Cellar/postgresql/10.4...
Error: Could not symlink share/man/man7/ABORT.7
/usr/local/share/man/man7 is not writable.
myname#MacBook-Pro-8 ~> sudo brew link postgresql
Password:
Error: Running Homebrew as root is extremely dangerous and no longer supported.
As Homebrew does not drop privileges on installation you would be giving all build scripts full access to your system.
I also tried:
brew prune; brew link postgresql
which gave me the same error:
Error: Could not symlink share/man/man7/ABORT.7
/usr/local/share/man/man7 is not writable.
Why is that folder not writable and what can I do to change that?
It was really painful solving this problem, so I figured I would leave it here for others to see.
Issue:
Homebrew install of Postgresql will not execute successfully. $ brew link postgresql results in failure due to directory not writable. New version of Homebrew will not allow sudo commands and System Integrity Protection prevents changing permissions.
Details:
I tried to use homebrew to install postgres and kept running into issues with syslink. When I ran $ brew link postgresql as homebrew suggested, I kept running into an error that it couldn't be completed because certain folders were not writable. I thought this would be easily remedied by running sudo but unfortunately the most current version of homebrew no longer allows the use of sudo commands due to security risks. My next thought was to my root user and use the macOS GUI interface to change the permissions on this folder because I am not sure how to do this on the terminal. Regardless of being logged in as 'root,' the OS would not let me change the permissions of the folder. I also attempted to use sudo and change the permissions in terminal and it did not work either. After several days of banging my head against the wall try all kinds of things to find a solution, I discovered that since El Capitan, macOS introduced System Integrity Protection aka 'SIP' or 'rootless.' As it turned out, once I disabled SIP, logged back into 'root' and changed my regular accounts permissions to Read/Write on the problem directories, I was able to go back to my regular account and successfully execute $ brew install postgresql.
(Assuming you currently have postgresql installed through homebrew but unable to link due a scenario like the one mentioned above, here is what I suggest to resolve your issue...)
Run $ brew link postgresql
Write down the directory path that the error says it is not able to write to. (e.g. usr/local/share/man/man7) NOTE: you'll want to actually write this down on paper or take a picture of the screen on your phone because you will not be able to use copy and paste)
Enable your 'root' user account if you have not already done so.
(instructions here) NOTE: make sure to make a really good password for this account and write it down somewhere safe. This is a powerful account and there's no way to recover the password.
Disable System Integrity Protection.
(instructions here)
Log into 'root' user account
In Finder menu bar select GO > GO TO FOLDER... (CMND + SHFT + G) and type in the path from Step 2.
Right-Click/ Cntrl-Click the folder and select Get Info
Click the plus sign at the bottom of Sharing & Permissions
Add your regular account to the list and change the permission to Read & Write
Go back to your regular account, run $ brew uninstall postgresql, then $ brew update and $ brew doctor . If those are all set run $ brew install postgresql.
You should be able to install without any problems now. However, if you run into a linking and permissions problem again, run $ brew link postgresql to figure out the problematic directory and repeat Steps 5 - 10 with whatever other directories are giving you trouble.
If everything is up and running properly. It is probably best to at least enable SIP again (instruction in the article linked in Step 4).
(To check that everything is working. I recommend running $ brew services start postgresql then $ createdb 'test' . In my case, it was when I originally tried to run createdb and got "command not found" that I realized something was wrong.)
Running this solves it. This gets around SIP.
sudo chown -R $(whoami) $(brew --prefix)/*
brew link postgresql

How to uninstall berrybrew—perlbrew for Windows?

I have been running berrybrew on Windows
(here's the home page and GitHub repository).
I'm having some trouble with it and I want to uninstall and reinstall it, but I can't figure out how to do that.
I am hoping it is as simple as just deleting the directory where it was installed and C:\berrybrew, which is where it seems to keep files, but I don't know for sure. The instructions contain installation instructions, but no uninstallation instructions.
Disclaimer: berrybrew author here...
To uninstall and return your system back to default:
berrybrew off
berrybrew unconfig
then delete the directory you downloaded it to, as well as the installation directory (by default, C:\berrybrew)
Edit your PATH variable to remove any entries that start with C:\berrybrew (or the base install directory if you've changed it from the default). One of the path entries will point to C:\berrybrew\bin, and there may be one more that points to the currently in-use Perl installation (also under C:\berrybrew\...). Technically speaking, there shouldn't be any after the first two commands are run, but one should always verify
Essentially, there's really nothing to "uninstall". It comes down to removing $ENV{PATH} ie. specific environment variables that point to a) berrybrew.exe binary itself, and b) the Perl installation that you last used.
I will update the documentation to provide more clarity in this regard.

Ember-cli 0.2.5 livereload keeps reloading in every change

After updating to ember-cli 0.2.5 (same think with 0.2.4; 0.2.3 was ok), when i make a change to a file and save it, it keeps reloading my app at least 3 times for each save i do. Server's console shows file added... file added... file added... for all my app files each time, but my tmp folder is always empty. Also is seems that for each reload it tries to create a folder inside tmp folder, but it quickly removes it every time. The only file inside tmp folder is .metadata_never_index. Does this have to do with caching? Any help? I'm on yosemite.
I had this problem with watchman 3.1.0 (which is the version that Homebrew installs) so I upgraded to 3.1.1 and it seems to have been resolved.
You'll need to install it from source, but it's easy:
$ brew uninstall watchman
Then just
$ git clone https://github.com/facebook/watchman.git
$ cd watchman
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
Fingers crossed it seems to have worked so far (thank goodness, as it was driving me CRAZY).
For anyone else that has the same problem, i reinstall node and watchman and now everything seems to work fine.
UPDATE I
It seems that the problem still exists. I have to mension that i'm using sublime text 3. When i restart sublime it seems ok, but after a save it starts reloading again and again. Anyone can help here?
UPDATE II
Removed watchman, falling back to NodeWatcher and all seems ok. But time to time i need to restart sublime text in order to boot up the ember-cli server. That seems to be a known issue...

I installed nvm n and now I keep getting "dyld: bad external relocation length"

I installed nvm, n, using sudo and decided to test it out by downloading several versions of node on my system. When I tried to switch between the node versions I kept getting "Permissions denied." So I decided to sudo the command for switching between versions too. That's when all hell broke loose. I keep getting
dyld:bad external relocation length
I've tried to reboot my terminal with some hope that it would magically fix itself out. Alas, I was wrong.Thanks in Advance.
Update 1: I've tried to use npm to install yo and it gives me the same "dyld" prompt, along with the following:
Trace/BPT trap: 5
Essentially I can't use npm anymore.
I had the same thing happen.
I was using a mac, so I downloaded the .pkg for the version of node I was interested in and re-installed it (which reinstalls npm at the same time).
Everything was back up and running after that.
I had the same this morning because of n package via npm,
Node was installed via brew (without npm), so i removed it this way;
brew uninstall node
then reinstalled the newer version via n package
n lts
if this is not enough because of policy rules of your mac, try
sudo npm lts
this solved my problem and saved a big time from reinstalling all global node modules.
Just use n reinstall node that you break in.
i solved my problem wihout uninstalling the nodejs,just update the node version by n, and it works.
sudo n latest

Unable to uninstall package inside virtualenv

I installed virtualenv + virtualenvwrapper via virtualenv-burrito. However, it seems to be giving me problems now in uninstalling packages from my virtualenvs (case in point, distribute).
It seems that the distribute used by my virtualenvs is the one at /home/skrd/.venvburrito. If, inside a virtualenv, I try to upgrade distribute, it installs to /home/skrd/.virtualenvs but the virtualenv itself is still using the one at /home/skrd/.venvburrito. With that, the packages needing an updated distribute still won't work.
See,
(test)$ $ pip uninstall distribute
Not uninstalling distribute at /home/skrd/.venvburrito/lib/python/distribute-0.6.27-py2.7.egg, outside environment /home/skrd/.virtualenvs/test
I've tried renaming the .venvburrito directory (equivalent to deleting it, but with back-up) but that breaks my virtualenvs. How do I uninstall packages now?
I still don't understand what happened here but I just had the idea to check what's installed for my system's Python outside virtualenv. There I saw distribute, with a similar version to the one that's giving me problems inside a virtualenv.
I upgraded the non-virtualenv installation of distribute and, next time I checked in my virtualenv, the distribute installation has also upgraded.
(So, yes, I'm aware that my question's original intent is to remove distribute. But that was just an intermediary step to updating it---the update was unable to proceed since it can't remove the distribute currently installed. So, there, problem solved.)