[BUG] Uninstall using sudo always fails the first time

[phatblat]

Describe the bug
It's a known limitation that the uninstall must be run using sudo. However, it always fails with the message "Error: Not installed" the first time the command is run using sudo. 2nd time seems to work fine.

$ mas info 883878097
macOS Server 5.7.1 [19.99]
By: Apple Inc.
Released: Sep 28, 2018
Minimum OS: 10.14
Size: 106.5 MB
From: https://itunes.apple.com/us/app/macos-server/id883878097?mt=12&uo=4

$ mas uninstall 883878097 --dry-run
==> Server /Applications/Server.app
==> (not removed, dry run)

$ mas uninstall 883878097
Warning: Apps installed from the Mac App Store require root permission to remove.
Error: Unable to move app to trash.
Error: Uninstall failed

$ sudo mas uninstall 883878097
Password:
Error: Not installed

$ sudo mas uninstall 883878097
==> App moved to trash: /private/var/root/.Trash/Server.app

To Reproduce
Steps to reproduce the behavior:

1. Run mas uninstall 883878097 --dry-run to verify app (macOS Server) is installed
2. Run sudo mas uninstall 883878097
3. See error
4. Run sudo mas uninstall 883878097 again
5. Observe success

Expected behavior
The first time the sudo mas uninstall 883878097 command is ran it should succeed.

Actual behavior
sudo mas uninstall 883878097 fails. It must be run a 2nd time.

Desktop (please complete the following information):

• mas version 1.6.2
• macOS version: 10.14.3
• How did you install mas? brew

Additional context
The uninstall command was added in 1.5.0 (#191)

[luzlab]

I experienced this same bug.
mas 1.6.2 via brew
macOS 10.13.6

[phatblat]

@luzlab did the command work the 2nd time you ran it through sudo?

[luzlab]

Yes, I had to run the command a 2nd time.

[mafredri]

Same here, didn't manage to reproduce after the first time.

Also, moving the app into /private/var/root/.Trash seems like something we would not want since there's no way to access or empty roots trash (correct me if I'm wrong). Is it a bug or do we need another method than sudo mas uninstall? For example, telling Finder to trash the app would pop up a permission request.

[aubreypwd]

I also have this same issue no matter how many times I use sudo... Seriously I can't mas uninstall <id> and there's no way to remove it from mas list

[mrolli]

I do have the very same issue and can't uninstall anything even on the nth attempt:

gimli in ~ $ mas version
1.8.2

gimli in ~ $ mas list
430255202   Mactracker                (7.10.7)
883878097   Server                    (5.11.1)
425264550   Disk Speed Test           (3.3)
764936294   Purple Tree               (3.3.4)
...

gimli in ~
2969 $ sudo mas uninstall 883878097
Error: Not installed

gimli in ~
2970 $ sudo mas uninstall 883878097
Error: Not installed

gimli in ~ $ sudo mas uninstall 883878097
Error: Not installed

gimli in ~ $ sudo mas uninstall 883878097
Error: Not installed

gimli in ~ $ sudo mas uninstall 883878097
Error: Not installed

gimli in ~ $ sudo mas uninstall 883878097
Error: Not installed

[fellnerse]

Same here, pls fix this

[chris-araman]

@fellnerse, pull requests welcome!

[fellnerse]

If you hint me in the right direction I'd love to help out

[tcurdt]

I do have the very same issue and can't uninstall anything even on the nth attempt:

I see the same thing on macOS 12.0.1 on a M1 with version 1.8.5.
No uninstall possible.

[chris-araman]

I wonder if the CKSoftwareMap cache for sudo is separate from that for the user. That would explain the initial "not installed" error.

Some possibilities for addressing this:

1. Instead of warning and failing when not run with sudo, perhaps mas could prompt for privilege elevation after collecting the bundle path, then trash with elevation. I'm not sure how to accomplish this on macOS, or if it's even possible as of Monterey.
2. Something might be found in CommerceKit, StoreFoundation, or another Apple framework that might provide a way to uninstall/remove an installed app.
3. mas could install a "blessed" launch daemon that would be responsible for uninstalling apps. Unelevated mas would request the daemon to uninstall an app. I'm not sure whether this is possible in Homebrew, or even advisable.

[fellnerse]

For me it would be enough in a first step that I can remove items from the list that are not installed anymore. Otherwise they end up in my brewfile when dumping my env.

[tcurdt]

For me it would be enough in a first step that I can remove items from the list that are not installed anymore. Otherwise they end up in my brewfile when dumping my env.

Using "AppCleaner" worked for me.

[chris-araman]

1. Instead of warning and failing when not run with sudo, perhaps mas could prompt for privilege elevation after collecting the bundle path, then trash with elevation. I'm not sure how to accomplish this on macOS, or if it's even possible as of Monterey.

Electron's app installer seems to use deprecated API AuthorizationExecuteWithPrivileges to remove an app bundle before replacing it.

3. mas could install a "blessed" launch daemon that would be responsible for uninstalling apps. Unelevated mas would request the daemon to uninstall an app. I'm not sure whether this is possible in Homebrew, or even advisable.

This seems to be what Apple's documentation would prefer mas does, but that does seem like rather a lot.

[chris-araman]

xcodes checks whether it's running under sudo by invoking sudo -nv. If it isn't, it queries for the user's password and passes it to sudo when executing additional commands. This wouldn't be ideal, but mas could in theory re-invoke itself under sudo if it implemented something like this.

Xcodes.app includes a privileged helper for performing tasks the require elevation.

[muescha]

same here with iOS 12.1 Monterey on a M1

> mas list | grep Numbers
409203825   Numbers      (12.1)

> mas uninstall 409203825 --dry-run
==> Numbers /Applications/Numbers.app
==> (not removed, dry run)

> sudo mas uninstall 409203825
Password:
Error: Not installed

> sudo mas uninstall 409203825
Password:
Error: Not installed

[sfosdal]

Same with macOS 13.1 22C65 arm64

Using AppCleaner to uninstall did work though.