Executing sudo as a non-admin user in macOS (OS X) and fixing "getcwd: cannot access parent directories" error

This is a weird one.

According to what I read online and in the Man pages, I should also be able to do something like this (where Fred is Admin account):

sudo -u Fred ls

That should ask for Fred's password then execute ls with Fred's privileges.

Except it doesn't. It runs against my non-admin account and fails. As though it were ignoring the -u flag. Instead I have to run

su Fred

to execute as Fred, then run sudo. [I think that su Fred sudo -u Fred ls should also work.]

I can't find anyone else who complains about this, so I assume I'm doing something wrong.
Note to test this you have to run from a non-admin account.

Update 8/23/2016: I can't get sudo to work at all in El Capitan for a non-admin users. Says: "error retrieving current directory: getcwd: cannot access parent directories: Permission denied."

Update 5/27/2018: I finally tried this in a different non-admin account. It works in Sierra in other accounts. So it wasn't El Capitan that broke this, it was something I did to my 18yo user account.

This is what I would see:

John-Air:~ myaccontname $ su Kateva
Password:
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
bash-3.2$ ls
ls: .: Permission denied
bash-3.2$

I searched around SuperUser for a while and got some hints. I deleted every user account Bash preference I could find. That didn't do anything. I repaired MacOS Sierra permissions using Onyx.app -- but as with every other time I'ver repaired permissions that produced many changes but no results. (It doesn't act on user folders.)

Eventually I realized the most likely explanation was the simplest one -- I'd somehow messed up permissions on the default account for Bash. By experimenting on my "good" non-admin user account I realized Bash default directory is the User account. So I compared User Account permissions and found this:



The problem directory was readable by 'everyone' but not by 'staff'. You'd think that 'everyone' would work ... but read this and weep. macOS permissions are a disaster. Don't even think about ACLs. It's a sign of the end-times really.

I couldn't see how to restore Staff. In the old days there was a utility for this, but that's long gone. Somewhere I found this advice to restore staff:

sudor chown $UID:staff /path/to/folder/modified/
chmod 644 !$

I ran it and staff was restored. When I logged back into my user account I was told macOS had to do something to enable me to run Applications! I entered my admin credentials and was asked again ... and again ... then I gave up and logged out. I logged back in and things .... seemed ... fine.

Now su works as it should.