I have installed El Capitan recently. I have successfully booted in recovery mode in el capitan and have typed in csrutil disable command from terminal.....
rebooted but even after repeated attempts it shows that :
SIP protection enabled(Custom configuration)
Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem protection: disabled
Debugging restrictions: enabled
Dtrace restrictions: enabled
NVRAM Protections: enabled
This is an unsupported.......
I have spent hours but cant figure out the issue.
Why cant i disable the the last three restrictions even after typing csrutil disable in recovery mode in EL Capitan?
I have tried multiple times and everytime i issue the CSRutil command in recovery mode; it says SIP successfully disabled; reboot for changes to take effect....
but after rebooting and loging onto normal mode when i check csrutil status: its shows the above status only..
Please help
It is possible to disable parts of SIP while leaving others enabled.
If you run csrutil status, even while booted normally, you will see the component parts of it. Each of these can be selectively disabled by running one of the following commands while booted into Recovery mode:
csrutil enable --no-internal
csrutil enable --without kext
csrutil enable --without fs
csrutil enable --without debug
csrutil enable --without dtrace
csrutil enable --without nvram
NOTE the use of enable and not disable
You can disable two or more components by structuring the command as follows:
csrutil enable --without kext --without debug
To Disable/ReEnable:
Boot to Recovery Mode.
Hold ⌘+R at startup before booting to apple logo.
Click on top of Utilities.
Click on Terminal.
Then type these commands.
To ReEnable, just simply replace "Disable"
with "Enable".
Disable NVRAM protection
csrutil disable --without nvram
Disable DTRACE
csrutil disable --without dtrace
Related
Launch any WSL from within VS Code "No WSL distros found. New distros can be installed from the Microsoft Store.
Source Remote - WSL (Extensions)
BUTON: "Add Distro" --> takes you to the store. Install the version of Linux, and try to start it and you get the following. I've had WSL working before and now cannot get it back to the original working WSL.
I tried some things to update to version 2 and I could list version with command "WSL -l -v" it showed up but not anymore. I've got the features set properly. WSL feature is enabled. I did try setting a bios "Virtualization Technology" this is on a HP laptop with AMD 64 bit cpu. That is off now after finding it doesn't help.
Features on: "Virtual Machine Platform", "Windows Hypervisor Platform" "Windows Subsystem for Linux" There are others but these seem relevant.
Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80370102
Error: 0x80370102 The virtual machine could not be started because a required feature is not installed.
Press any key to continue...
This had to have the bios setting. Also because of being Windows 10 Home didn't have Hyper V feature, but there is a batch that can add this. There is a msi to install WSL 2 so wsl.exe was upgraded. This got the results to show WSL version 2 for ubuntu-20-04 install Also there was some resets needed to get the "WSL -l -v" command to have running.
I don't know 100% certain that these are the cure to the issue. But may help someone who cannot get the Linux to start w/out various error running on windows subsystem Linux. Took me better part of a day to fix.
find the following by googling "del hyper-v.txt" you will hit a page telling you "How to activate Hyper-V in Windows 10 Home"
source of batch command
https://github.com/MicrosoftDocs/Virtualization-Documentation/issues/915
pushd "%~dp0"
dir /b %SystemRoot%\servicing\Packages\*Hyper-V*.mum >hyper-v.txt
for /f %%i in ('findstr /i . hyper-v.txt 2^>nul') do dism /online /norestart /add-package:"%SystemRoot%\servicing\Packages\%%i"
del hyper-v.txt
Dism /online /enable-feature /featurename:Microsoft-Hyper-V -All /LimitAccess /ALL
pause
Reboot, still not running, but needed the following sequence.
wsl --shutdown
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns
wsl -l -v
NAME STATE VERSION
* Ubuntu-20.04 Running 2
initially there was a root user only. Updated new user with the following in %userprofile% folder. Omit the dash and dot.
Ubuntu2004 config --default-user addedUsername
The WSL now is seen by VS Code extensions and no longer flagging to update to version 2. Now on to RxJS tutorial under VS Code.
Make sure all related settings in the bios are enabled.
Make sure all related features in the windows features are turned on.
Alright, if there is an error:
Turn off all related features
Restart it.
Turn on.
Restart it.
related features = ( virtualization )
EDIT: After setting the rabbitmq variables up in System Environment Variables and trying another un/reinstall the issue is resolved.
The following plugins have been enabled: rabbitmq_shovel
Applying plugin configuration to rabbit#MSGTEST01... started 1 plugin.
END EDIT
c:\RabbitMQ\rabbitmq_server-3.6.12\sbin>rabbitmq-plugins enable
rabbitmq_shovel rabbitmq_shovel_management Plugin configuration
unchanged.
Applying plugin configuration to rabbit#M... failed. Error:
{enabled_plugins_mismatch,"c:\Users\\AppData\Roaming\RabbitMQ
\ENABLE~1",
"c:\RabbitMQ\ENABLE~1"}
I set the following then reinstalled the service:
set RABBITMQ_BASE=c:\RabbitMQ
set RABBITMQ_CONFIG_FILE=c:\RabbitMQ\rabbitmq
set RABBITMQ_LOG_BASE=c:\RabbitMQ\logs
set RABBITMQ_MNESIA_BASE=c:\RabbitMQ\db
set RABBITMQ_ENABLED_PLUGINS_FILE=c:\RabbitMQ\enabled_plugins
Why is it still looking in my roaming profile for anything? Moreover, ENABLE~1 doesn't look like a valid filename.
I've tried blowing away my roaming profile data, RabbitMQ recreates the files.
I've tried copying my C:\RabbitMQ\enables_plugins to roaming, same thing.
Tried the reverse, same thing.
I've tried uninstalling and resintalling the service, same thing.
I'm able to enable the management ui after install, but not rabbitmq_shovel and cannot figure out what the issue is.
Again, this works after install:
rabbitmq-plugins enable rabbitmq_management
This fails with the error above:
rabbitmq-plugins enable rabbitmq_shovel
I'm running these commands as Admin in CMD.
Set up the variables in System Environment Variables and perform the following in CMD as Admin:
rabbitmqctl shutdown
rabbitmqctl stop
rabbitmq-service.bat remove
rabbitmq-service.bat install
rabbitmq-service.bat start
rabbitmq-plugins enable rabbitmq_management
rabbitmq-plugins enable rabbitmq_shovel
That worked for me.
I was able to fix the issue without having to uninstall RabbitMQ
Open the files named "enabled_plugins" at the two directory locations int he error your recived. For me, those directories were "C:\Users\UserName\AppData\Roaming\RabbitMQ" and "C:\ProgramData\RabbitMQ".
For me, one file had:
[rabbitmq_management].
while the other was empty. I copied the config snippet above into the empty file and saved it.
Run the commands as ADMIN in Command Prompt:
rabbitmqctl shutdown
rabbitmqctl stop
rabbitmq-service.bat start
rabbitmq-plugins enable rabbitmq_management
I did receive the same "enabled_plugins_mismatch" error; however, when I browsed to my RabbitMQ UI plugin at "http://localhost:15672/#/" the UI showed up and is functioning.
I just upgraded to MacOS Sierra, and I realized that I can't seem to run the "ssh -X" command in the Terminal anymore. It used to launch xterm windows, but now it's like I didn't even put the -X option anymore. It was working absolutely fine right before I updated. Other than going from OS X Yosemite to MacOS Sierra, I didn't change anything else in the setup.
EDIT:
As suggested, this is what I found in the debug logs that might be causing this problem.
debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
I didn't need to reinstall XQuartz, but, based on Matt Widjaja's answer, I came up with a refinement.
sudo vi /etc/ssh/ssh_config (This is ssh client config, not sshd_config)
Under the Host * entry add (or add where appropriate per-host)
XAuthLocation /usr/X11/bin/xauth (The location of xauth changed in Sierra)
ServerAliveInterval 60 (Pings the server every 60 seconds to keep your ssh connection alive)
ForwardX11Timeout 596h (Allows untrusted X11 connections beyond the 20 minute default)
No need to restart ssh, except, of course, existing ssh client connections.
It sounds like -Y (trusted X11) would be preferable to untrusted. If you switch over to trusted, the ForwardX11Timeout line can probably be removed.
The ServerAliveInterval line is also an optional preference.
It may also be possible to make these changes in ~/.ssh/config (the user's config file) but the permissions have to be correct.
EDIT: I removed ForwardX11 and ForwardX11Trusted. They aren't needed and ForwardX11 is less secure and causes problems for git (or other tools using ssh).
I noticed macOS Sierra resetted my X11 settings so that it disabled my xAuth program. To re-enable xAuth on macOS Sierra:
Reinstall X11/xQuartz to presumably reset any changes macOS Sierra made. I made the following changes below too although it sounds like this might be enough.
Load up a Terminal
sudo <text editor of your choice> /etc/ssh/sshd_config
In that file, uncomment the following lines, and set it to these values:
X11Forwarding yes
X11DisplayOffset 10
[Update on 10/07/2017] When you reinstall X11/XQuartz, above all else, it should add an: XAuthLocation <path_to_your_xauth> where mine was in /opt/X11/bin/xauth. This was probably the golden step that explained why reinstalling worked.
Restart ssh via the terminal. I did this by running:
sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
I'm having the same issues with X11 forwarding with the -X option after upgrading to Mac OS X Sierra.
Have a look at the ssh option -Y (trusted X11 forwarding). While using ssh -Y <host> things work for me.
It's an old question but I recently ran into the same issue on my Mac running 10.12.6. The DISPLAY variable is not set in the terminal and ssh -X doesn't work. This is what I did that solved the problem:
Reinstall XQuartz using Homebrew:
brew cask install xquartz (the option --forced may be necessary)
Add the XQuartz launcher to the system default (following the solution in this Reddit post:
launchctl load -w /Library/LaunchAgents/org.macosforge.xquartz.startx.plist
Restart the system.
After doing these, my DISPLAY variable is set properly:
$ echo $DISPLAY
/private/tmp/com.apple.launchd.mfXFpzZ0gC/org.macosforge.xquartz:0
And X11 forwarding in ssh works as well.
Just adding the one line XAuthLocation /usr/X11/bin/xauth to /etc/ssh/ssh_config works on my Mac, running MacOS Sierra, to ssh into a Linux host and be able to run X Windows programs remotely and have them display under XQuartz on my Mac.
My solution to this was the following.
(1) Launch xquartz before trying the ssh -X. In the xquartz options, I just enabled 'Open at login', and then it is always running in the background.
(2) Go to the xquartz Preferences menu, and on the Security window, click the box that says "Allow connections from clients".
After doing these things, everything works fine.
Just upgraded my macbook from El Capitan to Sierra. Simply reinstalling Xquartz has done the trick for me, using ssh -X [linux server]
I spent the whole day looking for solution only to realize that the recent Sierra does not ship with XQuartz installed https://support.apple.com/en-gb/HT201341. Upon install (https://www.xquartz.org/) all works.
If Quartz is installed, all that is needed is to add the line "X11Trusted yes" under "Host *" in the /etc/ssh/ssh_config file.
restarting XQuartz worked for me.
In my case, adding XAuthLocation /opt/X11/bin/xauth to /etc/ssh/sshd_config (note that it's not /etc/ssh/ssh_config) on macOS host worked after installing XQaurtz via brew install --cask xquartz as XQaurtz provide xauth binary
I am trying to install sip 4.18 and PYQt5. i have tried sudo but doesn't work. This is the error I am getting. Please help!!!
waheed$ sudo make install
Password:
cp -f sip /System/Library/Frameworks/Python.framework/Versions/2.7/bin/sip
cp: /System/Library/Frameworks/Python.framework/Versions/2.7/bin/sip: Operation not permitted
make[1]: * [install] Error 1
make: * [install] Error 2
I had exactly the same issue on Sierra.
This article explains the issue: http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-ars-technica-review/8/#h1
Solution:
You have to reboot in Recovery Mode (cmd+R while booting)
Open a terminal in Utilities
Disable the System Integrity Protection with this command: csrutil disable
Reboot
You can of course enable it again later.
It looks like in OS X 10.11 El Capitan, dtruss and dtrace can no longer do what they're meant to do. This is the error I get when I try to run sudo dtruss curl ...:
dtrace: failed to execute curl: dtrace cannot control executables signed with restricted entitlements
I've come across people noticing this problem but so far no solutions.
Is there a way to fix this or work around this?
Following up to Alexander Ushakov and Charles' answers:
Once you csrutil enable --without dtrace, there is an alternative to copying the binary: run the binary in one Terminal window and trace the Terminal process itself in another Terminal window.
In the first terminal window, find its PID:
$ echo $$
1154
In the second terminal window, begin the trace:
$ sudo dtruss -p 1154 -f
Back, in the first terminal window, run the process you want to trace:
$ ls
At this point, you should see the trace in the second window. Ignore the entries for the PID you are tracing (e.g., 1154), and the rest are for the process (and its descendants) you are interested in.
1154/0x1499: sigprocmask(0x3, 0x7FFF53E5C608, 0x0) = 0x0 0
1154/0x1499: sigprocmask(0x1, 0x7FFF53E5C614, 0x7FFF53E5C610) = 0x0 0
3100/0xa9f3: getpid(0x7FFF82A35344, 0x7FFF82A35334, 0x2000) = 3100 0
3100/0xa9f3: sigprocmask(0x3, 0x10BE32EF8, 0x0) = 0x0 0
For those who want to dtrace system shipped binary after csrutil disable, copyit to a directory that is not "restricted", for example, /tmp
CC#~ $ csrutil status
System Integrity Protection status: disabled.
CC#~ $ cp /bin/echo /tmp
CC#~ $ sudo dtruss /tmp/echo
SYSCALL(args) = return
thread_selfid(0x0, 0x0, 0x0) = 46811 0
csops(0x0, 0x0, 0x7FFF51B6CA20) = 0 0
issetugid(0x0, 0x0, 0x7FFF51B6CA20) = 0 0
shared_region_check_np(0x7FFF51B6A918, 0x0, 0x7FFF51B6CA20) = 0 0
stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF51B6BEA8, 0x7FFF51B6CA20 = 0 0
See #J.J's comment: https://apple.stackexchange.com/questions/208762/now-that-el-capitan-is-rootless-is-there-any-way-to-get-dtrace-working/224731#224731
As Andrew notices it's because of System Integrity Protection, also known as "rootless".
You can disable it completely or partially (enable just dtrace with some limitations).
Completely disable SIP
Although not recommended by Apple, you can entirely disable System
Integrity Protection on you Mac. Here's how:
Boot your Mac into Recovery Mode: reboot it and hold cmd+R until a progress bar appears.
Go to Utilities menu. Choose Terminal there.
Enter this command to disable System Integrity Protection:
$ csrutil disable
It will ask you to reboot — do so and you're free from SIP!
Partially disable SIP
Fortunately, SIP is not monolithic: it's built from many different
modules we can disable/enable separately.
Repeat steps 1 and 2 from «Completely disable SIP» section above. Now
in Terminal enter these commands:
$ csrutil clear # restore the default configuration first
$ csrutil enable --without dtrace # disable dtrace restrictions *only*
Reboot and enjoy your OS again.
Dtrace starts to work but you're still unable to attach dtrace to restricted processes
I would post this as a comment but I'm not allowed.
Disabling SIP is not necessary. Just copy the binary to an alternate location and it works just fine:
$ sudo dtruss ping google.com
dtrace: system integrity protection is on, some features will not be available
dtrace: failed to execute ping: dtrace cannot control executables signed with restricted entitlements
$ sudo cp $(which ping) .
$ sudo dtruss ./ping google.com
dtrace: system integrity protection is on, some features will not be available
SYSCALL(args) = return
PING google.com (172.217.10.78): 56 data bytes
^C
$ csrutil status
System Integrity Protection status: enabled.
For binaries that can still function normally after being copied, this is the best option as it captures the entire lifetime of the process and doesn't require disabling any protections.
Looks like completely disabling SIP still blocks dtruss for restricted processes:
$ /usr/bin/csrutil status
System Integrity Protection status: disabled.
$ sudo dtruss /bin/echo "blah"
dtrace: failed to execute /bin/echo: dtrace cannot control executables signed with restricted entitlements
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.11.2
BuildVersion: 15C50
See my answer on related question "How can get dtrace to run the traced command with non-root priviledges?" [sic].
DTrace can snoop processes that are already running. So, start a background process which waits 1sec for DTrace to start up (sorry for race condition), and snoop the PID of that process.
sudo true && \
(sleep 1; ps) & \
sudo dtrace -n 'syscall:::entry /pid == $1/ {#[probefunc] = count();}' $! \
&& kill $!
Full explanation in linked answer.