I had a client with an unusual issue on a Mac mini that used to be a file server, but now is just sharing out some archived content and their Munki repository.
There were just two users on this machine, one admin user that we used for interactive logins and administering the machine and one Sharing Only user.
The problem we had was that we needed to delete the Sharing Only user and recreate that user account as a standard user. Upon trying to delete the user in System Preferences, it asked for the password of that user (not the admin user) and even when the password was entered, the account couldn’t be deleted.
I also tried deleting the user using dscl in Terminal, but received an eDSPermissionError error and couldn’t do it.
I went through a couple of fixes from various web forums, but nothing seemed to work – I couldn’t delete this user.
Ultimately, I was able to go into /var/db/dslocal/nodes/Default/users and delete the .plist file that represented the user.
This won’t work on Mojave however as even if you have root access, macOS prevents you from going down any further than the nodes folder in dslocal.
FYI you can still do this in Mojave by booting up using command-R and then disabling system integrity. Once disabled you can delete the user plist and other associated data. Once done you can re-enable system integrity. See: https://www.imore.com/how-turn-system-integrity-protection-macos
That’s a good tip – I often forget about disabling SIP as it’s so rare to encounter an issue that disabling it will solve. This is indeed one use case where disabling it would definitely have helped.