I am always getting this error. What is the solution ?
As the error message says: your /etc/sudoers file has the wrong permissions.
the normal permissions (on OS X 10.10) are:
$ ls -l /etc/sudoers
-r--r----- 1 root wheel 1293 Sep 19 2012 /etc/sudoers
so get a root shell in some other manner and issue chmod 660 /etc/sudoers
and/or the appropriate chgrp and chown commands.
To get a root shell, it all depends on what you have left as assets.
The failsafe method would be from a recovery partition, but booting in single user mode should be enough in most cases.
Single user mode: boot holding "Command-S"
ref: https://support.apple.com/en-us/HT201573
Related
I have Windows 11. On it I installed Ubutu 16.04
While editing, I accidentally corrupted the /etc/sudoers. But before editining it I had created a backup of it by copying it as /etc/sudoers.backup
I tried to restore my sudoers file by typing
agrawa22#DESKTOP-B9E5HFJ:/srv/shiny-server$ sudo cp /etc/sudoers.backup /etc/sudoers
But I get error message
/etc/sudoers: syntax error near line 32 <<<
sudo: parse error in /etc/sudoers near line 32
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
I cannot open either /etc/sudoers or /etc/sudoers.backup because they are read only and cant be edited without sudo which is available no more.
agrawa22#DESKTOP-B9E5HFJ:/srv/shiny-server$ ls -lrt /etc/sudoers*
-r--r----- 1 root root 755 Oct 13 06:20 /etc/sudoers.backup
-r--r----- 1 root root 999 Oct 13 06:53 /etc/sudoers
What is the way to fix back my sudoers file? Also how could one avoid such messup in future and what is the best way to edit sudoers so that it can be restored from backup if needed?
As root (OS X 10.9.5), I cannot delete a file with no flags or ACL entry (at least seemingly), despite having the correct permissions:
/Library/LaunchAgents$ whoami
root
/Library/LaunchAgents$ ls -alOe
total 32
drwxr-xr-x 6 root admin - 204 Jan 12 22:56 .
drwxr-xr-x+ 66 root admin - 2244 May 9 15:26 ..
0: group:everyone deny delete
-rw-r--r-- 1 root wheel - 690 May 4 2016 com.bitdefender.antivirusformac.plist
/Library/LaunchAgents$ chmod -N com.bitdefender.antivirusformac.plist
/Library/LaunchAgents$ chflags 0 com.bitdefender.antivirusformac.plist
/Library/LaunchAgents$ rm com.bitdefender.antivirusformac.plist
rm: com.bitdefender.antivirusformac.plist: Permission denied
/Library/LaunchAgents$
The ACL entry above pertains to the /Library folder and shouldn't affect /Library/LaunchAgents. I have successfully moved other items in LaunchAgents while the bitdefender item fails. Have tried doing the above in single user mode as well with the same result.
What am I missing?
The purpose was to remove all traces of BitDefender. Having deleted its main folder where the files referenced in the plist resided, no daemons are running. I am however puzzled as to how this is possible.
There might be a kext that protects the file (the antivirus trying to "defend" itself), but sudo kextunload <name> (see the kexts with kextstat | grep -v apple) should work... Or, even better, first eliminate the daemon (vs agent) that controls it with sudo launchctl remove <name> (see the daemons with sudo launchctl list | grep -v apple).
I think it's taking advantage of OSX's System Integrity Protection model, but you don't need to worry about that.
They ship an uninstaller, it's just not very well documented. Here's how you get to it:
Open finder -> Utilities -> BitDefender Uninstaller.
I ran into some strange behavior while setting up a script to start kvm instances today, and am hoping you all can weigh in what's going on here.
Setup:
I have a script that starts a kvm with virt-install.
virt-install ... --disk=image.qcow2 ...
I want to run the same script on different versions of image.qcow2, so I created a symbolic link of a to my latest image.
My directory stucture would look something like this:
startKvm.sh
image.qcow2 -> image_v2.0.qcow2
image_v2.0.qcow2
image_v1.0.qcow2
However, when I tried to run my virt-install command, it returned the following error.
ERROR internal error: process exited while connecting to monitor:
datetime qemu-kvm: -drive file=/path/image.qcow2,if=none,id=drive-ide0-0-0,format=qcow2: could not open
disk image /path/image.qcow2: Could not open file: Permission
denied
Thoughts on the cause and alternate solutions?
I've had a similar idea to use symlinks, however in my scenario I run virt-manager via SSH with X forwarding as a user in wheel (admin) group. Creating a virtual guest produced same error:
Unable to complete install: 'internal error: process exited while connecting to monitor: 2018-02-24T07:53:19.064452Z qemu-kvm: -drive file=/var/lib/libvirt/images/archlinux-2018.02.01-x86_64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on: could not open disk image /var/lib/libvirt/images/archlinux-2018.02.01-x86_64.iso: Could not open '/var/lib/libvirt/images/archlinux-2018.02.01-x86_64.iso': Permission denied'
Issue is, in fact, with permissions. When setting up an .iso image using qemu-kvm, it changes its ownership to user/group qemu upon deployment. We need to make sure user qemu has access rights throughout whole path to the file.
Test case
User running virt-manager: yahol (wheel/admin group)
Iso or qcow2 image location: /home/yahol/isos/archlinux-2018.02.01-x86_64.iso
Note: please ignore the timestamps as I've hacked together this answer over 2 days. It was late and I was too tired to finish it the previous day.
Starting with image in user's home directory:
$ ll /home/yahol/isos/archlinux-2018.02.01-x86_64.iso
$ -rw-r--r--. 1 yahol yahol 565182464 Feb 24 08:49 archlinux-2018.02.01-x86_64.iso
Creating symlink as root in default path to KVM images:
# cd /var/lib/libvirt/images
# ln -s /home/yahol/isos/archlinux-2018.02.01-x86_64.iso
lrwxrwxrwx. 1 root root 48 Feb 23 21:35 archlinux-2018.02.01-x86_64.iso -> /home/yahol/isos/archlinux-2018.02.01-x86_64.iso
Symlink belongs to user root, while actual file still has user/group of a regular user.
Setting up and deploying virtual machine via virt-manager. Notice how user/group of image file changes to qemu:
$ ll /home/yahol/isos/archlinux-2018.02.01-x86_64.iso
-rw-r--r--. 1 qemu qemu 565182464 Feb 24 08:49 archlinux-2018.02.01-x86_64.iso
At this point VM manager, be it virt-manager or virt-install, throws the aforementioned error. This happens because user qemu doesn't have access to full path. Home dir of user yahol is only accessible to user yahol:
$ ll -d /home/yahol/
drwx------. 7 yahol yahol 258 Feb 24 08:37 /home/yahol/
Now let's create another path to which qemu has full access:
# mkdir -p /Qemu/Test/Iso
# mv archlinux-2018.02.01-x86_64.iso /Qemu/Test/Iso/
# chown -R qemu:qemu /Qemu/
# cd /var/lib/libvirt/images
# ln -s /Qemu/Test/Iso/archlinux-2018.02.01-x86_64.iso
# ll /Qemu/Test/Iso/archlinux-2018.02.01-x86_64.iso
-rw-rw-r--. 1 qemu qemu 565182464 Feb 23 08:53 /Qemu/Test/Iso/archlinux-2018.02.01-x86_64.iso
# ll /var/lib/libvirt/images
lrwxrwxrwx. 1 root root 46 Feb 24 09:39 archlinux-2018.02.01-x86_64.iso -> /Qemu/Test/Iso/archlinux-2018.02.01-x86_64.iso
This works perfectly fine, virtual machine has been deployed and it's running.
Possible solutions:
change ownership to entire path to actual image to user/group qemu
# chown -R qemu:qemu /Qemu/
give read+execute permissions to others (world) to entire path to image
# chmod -R o+rx /Qemu/
WARNING: This might have security implications!
create a directory owned by user/group qemu dedicated to iso images that will be symlinked
# mkdir -p /Qemu/Test/Iso
# chown -R qemu:qemu /Qemu/
Summary:
Even though everything is done by user with root privileges, the actual user working with VM images is qemu. Adding qemu to wheel group would still require providing means to authenticate and, since it's a no-login user, it might be tricky.
When I try to change the permissions for a file it doesn't seem to work. chmod says it is changing it but the file permissions remain the same. Can anyone explain what I am doing wrong? Here is a copy of my command line.
~$ sudo chmod -v u+x ex01
mode of 'ex01' changed from 0600 (rw-------) to 0700 (rwx------)
~$ ls -l ex01
-rw------- 1 user user 60297 Feb 6 21:50 ex01
Certain file systems, such as vfat, don't support Unix permissions. The owners and permissions of the files are decided when the file system is mounted. On vfat for example there is an option to set the permissions to whatever you want, and another that sets the execute bit only for .exe, .com, .bat and similar files. See https://www.kernel.org/doc/Documentation/filesystems/vfat.txt
I'm facing an annoying problem. It's been pretty frustrating. I am using a computer at my school to work on the Coursera Startup class. I am trying to connect to an Amazon EC2 instance. I downloaded the key pair. I check permissions.
mac5-library:startup roh21$ ls -l
total 6
-rw-rw-rw-# 1 roh21 108 1692 Jun 22 16:45 startup-class-key.pem
So, it's not secure. So I need to change the permissions. I try:
mac5-library:startup roh21$ chmod 400 startup-class-key.pem
mac5-library:startup roh21$ ls -l
total 6
-r--r--r--# 1 roh21 108 1692 Jun 22 16:45 startup-class-key.pem
Still has read permissions to everyone. Just to demonstrate what happens I do this:
mac5-library:startup roh21$ chmod 600 startup-class-key.pem
mac5-library:startup roh21$ ls -l
total 6
-rw-rw-rw-# 1 roh21 108 1692 Jun 22 16:45 startup-class-key.pem
Is it impossible to change permissions to the user without root permission? I'd be grateful for any kind of help.
Probably not related to initial questions problem, but can be useful. (especially to Unix novices like myself)
Chmod will not work if you are not an owner of resources.
You should run chown first:
$ sudo chown -R $(whoami) .
and then
$ sudo chmod -R +rwX .
First command will change owner of everything in current folder to be logged in user, and second give them read write execute permissions.
Just for example, you, probably, should not change ownership and permissions so boldly.
I copied the file to my ~/.ssh folder and then changed the permissions with chmod. That did it.
Just to provide more information, the permissions for the ssh folder,
drwx------ 8 roh21 108 272 Jun 26 17:26 .ssh
And the permissions to the folder I used initially
drwxrwxrwx 2 roh21 108 2048 Jun 23 06:32 startup
I curious as to why I could not change the permissions to the startup folder even after multiple attempts with the chmod -R option.
Also, note that I was using Mac OS X in my school's library.
See that '#' next to the mode flags? That means that there's extended metadata associated with the file. Use ls -l# to see it. The xattr command will let you view and modify them. It's possible that there's something there that prevents you from modifying the file.
There may also be additional file flags. Use ls -lO (capital-O) to view those. Odds are that one of those flags is the "uchg" flag which means your file is immutable. You can remove that with chflags nouchg <filename> as أحمد طه suggested.
Finally, there might be an ACL attached to the file. Use ls -le to see that.
In general, if you really want to know all the metadata associated with a file on a Mac, the command is ls -leO#.
Looks like you've discovered that the Macintosh doesn't strictly agree with the UNIX permission bits.
Ultimately, there are ACL bits that MacOS sets and that the Macintosh Finder obeys.
To solve your problem quickly, in your Terminal command line, type in "open ." (or the path to your "startup" folder) and that will open up the folder in your Macintosh Finder.
Then do a "Get Info" on the file:
You can change your permissions here.
Hello And it will work
chflags nouchg /path/folder/
Please note you may get "Operation not permitted" at your Terminal when you want to run "chflags nouchg". So, first you should give your Terminal "Full Disk Access" here:
System Settings --> Privacy & Security --> Full Disk Access --> check the Terminal
then close and re-open your Terminal.
Now, run "chflags nouchg PathToYourFolder"
Finally:
chmod 400 YourFile
Done!