/etc/sudoers is owned by uid 503, should be 0 - El Capitan - macos

Whenever I try any Sudo commands in terminal, I get the following error message:
sudo: /etc/sudoers is owned by uid 503, should be 0
sudo: no valid sudoers sources found, quitting
I have tried logging into single user mode and typing in the following commands:
mount -uw
chown /private/etc/sudoers 0
After typing in the chown ownership line, I get an error message saying
“illegal username”.
Other things I have tried:
Reinstalling the os (El Capitan)
Disabling System Integrity Protection (SIP).
Calling Apple Care who say that Sudo commands have been disabled in El Capitan.
Logging in under Single User mode and typing in the following code:
chown root:wheel /private/etc/sudoers
This produced the error message “Operation Not Permitted” in my Standard, Admin, and Root accounts.
The error message “Read-Only File System” came up when I logged tried the code in Single User Mode.
FYI
When I run ls -la /private/etc/sudoers in Terminal, I get the following:
-rw-r-----# 1 MY-ADMIN-USERNAME staff 67 18 Feb 14:03 /private/etc/sudoers
Note I’ve replaced my actual admin username with “MY-ADMIN-USERNAME” just so you know what’s showing.
I need Sudo commands to work for a range of reasons, one of which is to get CrashPlan to work.
My hardware is a 2010 iMac, 3.2GHZ, 16GB Ram and 500GB SSD which was installed about a year ago.
These problems have only come up with El Capitan. I didn’t have them in the past with Yosemite. Downgrading is likely to be a problem as Migration Assistant gives problems when trying to port the data across by telling you that Time Machine is working off a later version of OsX.
Looking around online, I can see that many people have had similar issues but the resolutions that have worked for them unfortunately have not worked for me.
Any suggestions would be greatly appreciated.

The correct chown syntax is
chown 0 /private/etc/sudoers

try running the command from another operating system, so for example from a mac os x 10.9, or 10.10 partition:
sudo chown 0 /Volumes/NAME_OF_VOLUME/private/etc/sudoers
This is what worked for me. you might also be able to do this from a 10.9, or 10.10 recovery usb environment.

Related

Read-only file system" with SIP disabled in macOS Catalina

I am trying to copy some files from a path to my libs path (/usr/lib), I am trying with sudo cp {my file}/usr/lib/
bit I got this error.
/usr/lib/{my_file} Read-only file system
I have validated and indeed System Integrity Protection is disabled (SIP) I am using macOs Catalina 10.15.4
I Hope you can help me thanks.
You just should try with
sudo mount -uw /
it should work
I just recently joined stack overflow so I am not able to up-vote the above answer. Using sudo mount -uw / definitely works. In my case I needed to add a small script to /sbin to overcome an issue with VMware Tools. Starting with macOS Catalina, disabling SIP and then executing this command as root was the answer.
I'm also new to stack exchange, but want to add that
"sudo mount -uw /" worked. Thank you #Juanse
In my case, was suffering from the problem of Kernel_Task using more than 500% of CPU on my Mid-2012 15 MacBookPro aka (MacBookPro9,1 ) with quad-code Intel Core i7.
After multiple solutions did not work, I went on to try a solution posted at: https://discussions.apple.com/thread/8461404?answerId=33657338022#33657338022
Which instructed me to:
Reboot into recovery mode.
Select Utilities/Terminal, csrutil disable , reboot.
cd:
/System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources
move or delete a file based on my version of Mac as listed in the thread. For my MacBookPro9,1 the file 4B7AC7E43945597E.plist
Reboot into recovery mode
Select Utilities/Terminal, csrutil enable , reboot.
The problem with the solution, is that when I tried to "mv 4B7AC7E43945597E.plist ~", or even "sudo mv 4B7AC7E43945597E.plist ~", I got a read-only file system message. Running "sudo mount -uw /" made the file system writeable. Note that the steps of booting into recovery mode and disabling / enabling csrutil turned off, and then back on the apple System Integrity Protection (SIP), which is necessary if you wish to change certain key system or configuration files.

Lost permission for sudo in OSX El Capitan

I'm new to using OSX (using El Capitan 10.11.3) and while trying to change permissions on a file using sudo, I accidentally corrupted it. Now whenever, I try to use sudo to install anything globally, I'm getting the following error message.
sudo: unable to stat /etc/sudoers: Permission denied
sudo: no valid sudoers sources found, quitting
Is there any way to solve it?
I'm also unable to even view the /etc folder
bash: cd: /etc: Permission denied
When I checked permissions on /etc folder, they are as follows
lrwxr-xr-x# 1 root wheel etc -> private/etc
I had the same issue and in my case the permissions of the root folder got corrupted. What people overlook is that / is in fact also a real, normal directory and just like every directory it has ownership and permissions. Ownership should be root:wheel and permission should be 755 (that's rwxr-xr-x).
The easiest way to restore both was starting Script Editor and then typing and running that script:
do shell script "/usr/sbin/chown root:wheel /" with administrator privileges
do shell script "/bin/chmod 755 /" with administrator privileges
You are prompted for amdin password and then chown and chmod come to the rescue. After that sudo was working again.
Disable System Integrity Protection (rootless)
Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot OS X into Recovery Mode
When the “OS X Utilities” screen appears, pull down the ‘Utilities’ menu at the top of the screen instead, and choose “Terminal”
Type the following command into the terminal then hit return:
csrutil disable; reboot
You’ll see a message saying that System Integrity Protection has been disabled and the Mac needs to restart for changes to take effect, and the Mac will then reboot itself automatically, just let it boot up as normal

How do I force-delete a file on my computer?

I am using Mac OS X El Capitan Public Beta 2.
There is somehow a permission problem with my Desktop (and only this directory) because I can not delete any file.
The classic delete to bin does not work, even though I am prompted a window asking for my password and permission. (I am the administrator).
I also tried a few command lines like sudo rm - R *file* and it tells me that the operation is not permitted even after I enter my password.
Going without the rootless feature of El Capitan did not help either :
sudo nvram boot-args="rootless=0"
sudo reboot
Should I change the permissions of the Desktop directory? If so what are the original ones?
Thank you!
This could be caused by the "rootless" feature introduced in El Capitan... You can find more information about it here .
To disable "rootless", type this in the terminal (you'll have to reboot for the change to apply):
sudo nvram boot-args="rootless=0"
sudo reboot
After numerous try the answer was dead-easy : there is a "lock" option on files and directories in OS X and it was active for my desktop (right click -> information). Interesting is the fact that no command line could break it.

Repairing Postgresql after upgrading to OSX 10.7.3 Lion

I have the issue described in:
Repairing Postgresql after upgrading to OSX 10.7 Lion
but didn't get it solved.
The Postgres application generating the error is at /usr/bin/psql,
but the correct one is at
/Library/PostgreSQL/9.1/bin/psql.
When I add the later to my path in .bash_profile (or even in /etc/paths), uninstall and install the PG gem, then I still receive the error:
.rvm/gems/ruby-1.9.3-p0/gems/activerecord-3.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:1161:in `initialize': could not connect to server: Permission denied (PG::Error) Is the server running locally and accepting
I tried it several times, also with the option:
-- --with-pg-config=/Library/PostgreSQL/9.1/bin/pg_config
Any idea?
EDIT:
After reading through more posts (like http://www.iainlbc.com/2011/10/osx-lion-postgres-could-not-connect-to-database-postgres-after-homebrew-installation),
I just did the following:
sudo ln -s /private/tmp/.s.PGSQL.5432 /var/pgsql_socket/
And it worked. I don't know at all why. Do I have two installations of Postgres? Where is the app laying behind the /usr/bin/psql file?
After running find / -name .s.PGSQL.5432 -ls, I noticed that the result was:
47366187 0 srwxrwxrwx 1 postgres wheel 0 Dec 3 15:15 /private/tmp/.s.PGSQL.5432
Note that the PGSQL socket file is /private/tmp/.s.PGSQL.5432
Using your suggestion above (but modifying it a bit), I did this:
sudo ln -s /private/tmp /var/pgsql_socket
Restarted terminal and it worked.

PostgreSQL permissions issue after upgrading to OS X Lion

After upgrading to Lion, I get the following error when trying to start up the Postgres server:
pg_ctl: could not open PID file "/usr/local/var/postgres/postmaster.pid": Permission denied
I also tried to re-run the initdb command, but ran into a similar problem:
initdb: could not access directory "/usr/local/var/postgres": Permission denied
If it matters, PostgreSQL was installed via Homebrew. Running brew info postgresql yields the expected results (version, summarized docs).
Well, it turns out the solution was pretty simple. I changed the group on /usr/local/var to staff (from wheel) and changed the ownership (chown -R) to my system account (from root).
After that, postgres started up fine.
I was a little nervous changing those permissions, but the only thing in my /usr/local/var was a postgres directory, so all should be well. If you have other directories/files in /usr/local/var, maybe don't use the -R flag when chown'ing?
The Homebrew ruby installer script changes the group of /usr/local/var to staff, so that must have gotten undone when upgrading to Lion. Not sure about the ownership being root instead of my system account though...
sudo chown -R $(whoami) /usr/local/var

Resources