Installation fails if external drive is plugged in

[acurrieclark]

Your Environment

• mas version: 1.8.7
• macOS System Version: macOS 15.1 (24B83)
  Kernel Version: Darwin 24.1.0

mas Install Method

• brew install mas (homebrew-core)
• [] mas-cli/tap
• [] .pkg installer from releases
• [] Built from source
  • Fork/branch: ? (e.g. mas-cli/main)
  • Xcode version: 10.?

Describe the Bug

Attempting to install a package fails whilst an external hard drive is plugged in. The installer gets all the way through the installation and fails when it attempts to clear up. For some reason, it seems to be trying to move files in to the .Trashes directory on the external drive.

For example:

$ mas install 310633997
==> Downloaded WhatsApp Messenger (24.23.80)
==> Installing WhatsApp Messenger (24.23.80)
Error: Download failed: “WhatsApp” couldn’t be moved because you don’t have permission to access “Trashes”.

Unplugging the drive fixes the issue.

To Reproduce

Plug in an external drive and try to install an app.

Expected Behavior

The app should install without issue.

Actual Behavior

The installation fails, as above

[rgoldberg]

Are you familiar with Xcode enough to debug the mas code to isolate the line on which the error occurs?

I guess the last line of mas Swift code in the stack trace when the error occurs would be:

mas/Sources/mas/AppStore/SSPurchase.swift

Line 63 in 63dc7f1

.perform(self, withOptions: 0) { purchase, _, error, response in

Did mas install work with the same external drive (or other external drives) attached beforehand, either using older versions of mas and/or installing other apps?

Does the external drive contain any WhatsApp.app application folder or any other *.app application folders?

What user owns Trashes on the drive & what are its permissions?

What file system is used on the external drive?

Thanks for any info that might be useful.

[acurrieclark]

Not sure I would know where to start with Xcode when it comes to debugging a CLI app, I afraid. However:

Does the external drive contain any WhatsApp.app application folder or any other *.app application folders?

I think you have hit the nail on the head here. There is indeed a copy of Whatsapp on the external drive. The last time I saw the issue I was trying to install Pixelmator Pro, with the same result. I hadn't twigged it was anything to do with the external drive until today.

By the looks of things, this might be related to the fact that apps can now be installed on external drives, as of OS X 15.1.

[rgoldberg]

Thanks for the info.

We tried to limit mas to only looking at apps under /Applications, but we use various functions from Apple private frameworks that probably cannot be configured to such a limitation. mas probably can only limit its searches (as per the existing code), not the install behavior, unless we completely revamp install, which might be impossible / difficult to research.

mas could output better error messages in the case, but it would require isolating what throws the error. I, however, cannot test this issue because I won’t have Sequoia until the M4 Mac Studios are released, presumably in summer 2025.

I assume the WhatsApp app on the external drive isn’t stored under any symlink under /Applications, it’s just somewhere on the external drive, and Apple sees it.

Can you provide the owner & permissions for the Trashes folder on the external drive, and what type of file system it uses?

[acurrieclark]

The drive in question is a backup drive I was using to format and reinstall my mac. The applications in question all reside in the /Applications directory on that drive. No symlinks.

The owner of .Trashes on the external drive is acurrieclark and the group is staff.

[rgoldberg]

Thanks for info.

Is there a Trashes (no leading dot) folder anywhere on the drive?

The error message is from Apple code; it says Trashes not .Trashes, so maybe some other folder is causing problems (or maybe the error message is just incorrectly worded).

[acurrieclark]

Only with the leading dot, I am afraid. It's essentially the directory structure of a bootable OS X drive.

The permissions on the directory are d-wx--x--t, so no-one has read access and only the owner can write.