Running sudo commands recently started failing with "sudo: 3 incorrect password attempts". I've validated the user account is an administrator. It takes the password when making system-level changes in System Settings or Finder. Verified it's a member of 80(admin): $ id -a | grep -o '[0-9]\+(admin)' 80(admin) Affects any commands such as sudo ls sudo mkdir / This affects 2 machines. One of them is my test Mac - Duplicated the issue with 2 other accounts that had existed before the issue started (both have admin access). Created a new account and duplicated the issue. More on the other machine in a sec. Little back story: I was setting up NIST "800-53 R5 High" security baselines (https://github.com/usnistgov/macos_security) and deployed the configuration profiles, policies, and script via Jamf Pro to a couple of machines. A team member who was helping QA/QC the effects of the security baselines reported no longer being able to authenticate to Bitbucket. While trying to resolve the Bitbucket issue (command below) we found that he could no longer run sudo commands. sudo /bin/launchctl disable system/com.openssh.sshd I don't have TextExpander installed on my test machine. The /private/et/sudoers file looks fine - I've compared it against files from unaffected machines. It does have entries: root ALL = (ALL) ALL %admin ALL = (ALL) ALL There's a red minus sign on /private/etc/sudoers.d/ and Fider throws a "you don’t have permission to see its contents" when trying to drill into the folder. I booted to single user mode, ran chmod -R 0440 /etc/sudoers.d, rebooted, and duplicated the sudo issue and the permissions error trying to open sudoers.d. Running chmod -R 777 /etc/sudoers.d allows me to drill into to sudoers.d but still can't run sudo commands. Within sudoers.d there's a file named mscp. I've seen the file with the same name on other test machines, but while the file's identified as file type = Document on those machines it's listed as Unix Executable File on my test machine. I tried copying the file from on of the machines over to the affected machine (temp folder /User/Shared/mscp), booted to single user mode, copied /User/Shared/mscp to /Volumes/Macintosh\ HD/private/etc/sudoers.d/, and rebooted. Still experiencing the sudo password issue and mscp is still listed as Unix Executable. Not sure if the issue lies with the mscp file or something else.

I'm trying to enter into superuser using sudo su but it's not working, I'm getting following output on screen, sudo: /etc/sudoers is world writable sudo: no valid sudoers sources found, quitting sudo: error initializing audit plugin sudoers_audit even when I try, sudo reboot it's showing same output and not rebooting. I don't know if any file is broken or corrupted on my system. Changing permissions is also not working out for me. Getting following output, chmod: Unable to change file mode /etc/sudoers: Operation not permitted Thanks in advanced.

Can Touch ID on Mac authenticate sudo in Terminal?

I do most of the "work" I do on my Mac as a Standard user (Apple parlance for an *unprivileged* user). I also frequently use the CLI (zsh mostly now) via the Terminal app. I use [MacPorts](https://www.macports.org/) as a *package manager*, and various utilities such as find, rsync, launchctl, ip, mount, log, softwareupdate, etc etc etc. As it frequently happens, something I am trying to do from the CLI requires *privilege elevation* via the sudo command. However: According to [this document](https://support.apple.com/guide/terminal/enter-administrator-commands-apd5b0b6259-a7d4-4435-947d-0dff528912ba/mac) , it seems that Apple does not support the use of sudo by Standard users: >Only administrator users can use sudo. If you’re not logged in as an administrator, you can do so by entering the following command, where **adminUsername** is the name of an administrator user: >***% su adminUsername*** This seems clumsy and inconvenient: su and then sudo. It is also at odds with the way sudo works on other platforms I use. Of course macOS requires Admin user authentication to perform some tasks in the GUI, but this is *generally* not the way that sudo operates; i.e. ***any*** user may be granted privileges to perform specified tasks by the Admin user for the system. I won't ask "why" Apple does it this way as that can only be an *opinion* here, but I will ask if there is a *work-around* - can sudo on macOS be made to work as it does on other platforms?

I'm new to Mac as a system, so please be patient. I was wondering of there is a way to use the automator app to run the a command when my account logs in: sudo nvram AutoBoot%=00 I'm on Mac Pro 2021, with intel i7 and Sequoia 15.1.1 Is there a guide for getting started with automation on macOS?

I'm using macOS catalina 10.15.7. I recently found out i cannot run sudo anymore, tried to run sudo brew install nats-server, and got this message: is not in the sudoers file. This incident will be reported. I got my username by whoami. By running id, i see 80(admin) was listed there. Went to System Preferences -> Users & Groups, I saw my name (full name not my username) is listed under Current User as Admin, Mobile. Followed other posts online, i was able to find /etc/sudoers.d folder and sudoers file, and right click get Info, i added my username back to the permission list which allow me to read and write, the changes were made to both /etc/sudoers.d folder and sudoers file. At one point of time i was able to run sudo visudo /private/etc/sudoers and found out the line for admin was commented out, so i removed the comment to re-enable it, now the file has root and admin enabled, no other user: root ALL = (ALL) ALL admin ALL = (ALL) ALL and at the bottom of the file, i saw: ## Read drop-in files from /private/etc/sudoers.d ## (the '#' here does not indicate a comment) #includedir /private/etc/sudoers.d after all these changes i still cannot run sudo: sudo brew update sudo: 4294967295,2416387072,32767,0,0,0,0,0,0,0: invalid value sudo: error initializing audit plugin sudoers_audit sudo brew update Password: is not in the sudoers file. This incident will be reported is admin and my username the same user? it should be, right? do i have to add my username in /private/etc/sudoers file separately? Update: run id -un, it shows my username run ls -l /etc/sudoers, it shows: -r--r-----+ 1 root wheel 1562 Jun 29 10:06 /etc/sudoers

I think I may have corrupted my sudoers file. At any rate I can no longer use the sudo command (always hangs). I've read other questions related to this topic and tried to fix (going into Recovery mode for ex) but feels like I don't know what I'm doing. Pretty sure I caused the problem by using chmod to grant permissions too widely to a folder. This is not uncommon apparently. Running things like sudo visudo or sudo lsof -i yield: sudo: /private/etc/sudoers.d is world writable This is a brand new macbook M3 btw. Was working on getting nginx going, but the certbot process wrote the wretched file to a dir unexpected by the instructions I was following, and log revealed that permission was being denied to private/etc. Trying to obtain permission there with Finder and Terminal is what caused this. **UPDATE:** my /private/etc folder's permissions now seem to have been corrected, as per advice from Linc D below. But although invoking sudo no longer responds with sudoers.d is world writable, it now simply hangs. I think the problem is now with the /etc/sudoers, but the permissions on /etc seem to be messed up. Looks like this. Notice difference between it and /private/etc

After installing prebuild mc binary to Mojave and newer (link and link 2 ), and trying to run mc under root with sudo command, I got error: $sudo mc common.c unimplemented subshell type 1 read (subshell_pty...): No such file or directory (2)

In macOS there are a lot of pre-installed bloatware applications. I know that I will never use them. Examples of such apps are: Chess, Stocks, Messages, TV and so on. While some of them may not take up much disk space, they are cluttering the application list and Launchpad menu, so I wanted to get rid of them. When I tried to delete such applications, I got an error saying that I have no permission to do it. So is it possible to remove apple bloatware from macOS? There was the same question in 2011 and in 2012 . They contains info that is no more actual. This question is an update for 2021. I am asking about macOS v10.15.7 (Catalina) or later.

**System:** macOS 14.6.1, M2 MacBook Air I'm trying to use a regex pattern match in my suoders file. According to the man sudoers manpage as well as the online docs , that should be supported with sudo v1.9.10 or higher. Running sudo --version on my system yields 1.9.13p2 so, should be ok there. Also, running the syntax check command below indicates that the file is being parsed successfully:

$ sudo visudo -c
/etc/sudoers: parsed OK

Here's an example line from my sudoers file which ***DOESN'T*** work:

luke  ALL=(ALL) NOPASSWD: /bin/launchctl asuser ^[0-9]+$ /usr/sbin/screencapture -D1 -p

And here's are two similar commands using regular wildcards/globs that **DO** work:

luke  ALL=(ALL) NOPASSWD: /bin/launchctl asuser ??? /usr/sbin/screencapture -D1 -p

luke  ALL=(ALL) NOPASSWD: /bin/launchctl asuser * /usr/sbin/screencapture -D1 -p

I've done as much debugging as I can but remain flummoxed. Anyone got thoughts?

I'm on a machine with zero admin access and zero possibility of obtaining said access. Is there a way for me to accept the license agreement without knowing the admin password?

I'm running a fresh install of Sequoia, currently a macOS Sequoia 15.0.1 arm64 on MacBook Pro (14-inch, 2021) with Touch ID. I tried to enable Touch ID for sudo and the config files now look like: cat /etc/pam.d/sudo # sudo: auth account password session auth include sudo_local auth sufficient pam_smartcard.so auth required pam_opendirectory.so account required pam_permit.so password required pam_deny.so session required pam_permit.so and cat /etc/pam.d/sudo_local # sudo_local: local config file which survives system update and is included for sudo # uncomment following line to enable Touch ID for sudo auth sufficient pam_tid.so This does direct the authentication request to the system, instead of the Terminal password prompt. But now I get a system password prompt and not the desired Touch ID prompt. Touch ID does work. Other prompts also require my fingerprint. This seems to be specific to the Terminal. Any suggestions on how to solve this are welcome. Update: This behaviour only happens when my MacBook is docked to my Dell USB display. One it's undocked everything works as expected...

Does the usual auth sufficient pam_tid.so in /etc/pam.d/sudo or /etc/pam.d/sudo_local work on macOS 15 Sequoia (e.g. as described in this question )? I upgraded yesterday and went to re-apply this setting that lets you use touch ID with sudo but I noticed that there is no "pam_tid.so" file anymore in /usr/lib/pam the file is now "pam_tid.so.2". Maybe the 2 postfix is because it's multi-architecture binary? I'm on an M2 mac. I'm just wondering if anyone else has confirmed touch ID works the same, or if we should use the filename with the ".2". I've searched a bit but not found anything. I don't want to break sudo access, it can be a real pain, so I'm hesitant to test.

I have enjoyed the seamless integration and convenience offered by the Apple Watch to unlock my MacBook and authorize various actions without the need for password inputs. This has been particularly useful when my MacBook Pro's lid is closed and I'm operating in clamshell mode with external peripherals. But I don't know when behavior changes. Detailed Description of the Issue: With my 16-inch MacBook Pro, 2019 model (intel), I have noticed a change in how the system responds to authentication requests. While I can still unlock my MacBook Pro using my Apple Watch, I am no longer able to authorize certain actions, such as using sudo in the terminal or accessing applications like Dashlane. Previously, my Apple Watch would facilitate these actions without requiring me to input a password, even with the MacBook lid closed. This has changed; now, when my MacBook Pro lid is closed, I am compelled to enter passwords manually for actions that my Apple Watch should authorize. Or quip it open. If anyone has a hint on how to troubleshoot this issue, it will be appreciated.

Running zsh on macOS Ventura → With sudo --preserve-env -s the environment variable ZDOTDIR is not preserved but all the others are. → With sudo --preserve-env=ZDOTDIR -s the variable ZDOTDIR is preserved but not the other variables. Why is ZDOTDIR not preserved in the first case ?

I have a script that calls hidapitester binary. But I have to run this script with sudo privileges. If it's not called with sudo then it throws an error: Error: could not open device. Instead of always typing my sudo password when calling this script, is there any way to call this without asking sudo password? Or always-run with root privileges without sudo?

I now have a prompt that recurs every 30s wanting me to allow running some unknown sudo script. The prompt is a macos builtin prompt that takes the center of the screen and can lose focus but can't be moved or minimized. It is what you would expect to get if you ran something like sudo htop on the command line. Specifically it reads: > sudo is trying to execute a command as administrator. > Touch ID or enter your password to allow this. Obviously I'm not going to allow it because I don't know what it is. Hitting cancel works, but it pops back up 30s later. Is there any way to track down what program is causing it? If it matters at all, this is an M2 running Sonoma 14.5 Seems like this questions

I've been trying to run the logger command in terminal but it only works with sudo. How do I allow it to work in terminal without the sudo command? I'm trying to run the logger command from sleepwatcher (it doesn't seem to work in other apps like keyboard maestro). I've tried to update the privileges of the system.log file to allow more permissions. Perhaps it is a permissions problem because it runs in sudo mode and in terminal. This doesn't log anything when run in terminal (or sleepwatcher or keyboard maestro or anywhere else) logger -p info -t atreeon_test "hello" This does log correctly when run in terminal sudo logger -p info -t atreeon_test "hello";2

Can I run command sudo ipconfig set en0 DHCP as a standard user whithout request for my password?

I used to use auth sufficient pam_tid.so in the /private/etc/pam.d/sudo file to allow fingerprint authentification when using sudo command. Recently upgraded my MBP for a new M1 under macOS Big Sur (11.1), and the change still works. However, suddenly, this stopped working. Instead of asking for fingerprint, it asks me for password in the GUI (not in the terminal). After digging around, I did a macOS recovery install and it resolved the problem. Today, the problem appears again but the recovery install didn't fix it. I just discovered that this only happens when my MBP is docked to my docking station with 4 external screens and hard drive. I need to understand what is causing this issue, I guess this may be related to the display link USB video driver. Has anybody an idea on what's going wrong?