macOS OneDrive, ScanSnap PDFs and the "could not be opened" error in Monterey

When I migrated from Mojave to Monterey I ran into the typical array of macOS upgrade issues -- including having to reinstall Monterey. There's a reason I dread updating macOS.

One of the issues was that OneDrive didn't seem to work with my ScanSnap PDF uploads. In this case there were two suspects - the Monterey update and a OneDrive update. (One of the reasons I upgraded after migrating off Aperture was that OneDrive was no longer supported.)

The iOS ScanSnap client seemed to work as before, and the PDF appeared in the OneDrive folder I used -- but the file could not be displayed by Preview. I got a "could not be opened ... It may be damaged or use a file format that Preview doesn’t recognize."

It took a few searches to find the answer ...

If you were previously navigating to useraccount/OneDrive/DocumentFolder and opening your files from there, that seems to have stopped working now, and you have to go to Locations/OneDrive/DocumentFolder instead.

I'd had a Favorites link to the OneDrive folder that held my scans prior to the update. When I study where that link goes now it's not to the old file system folder, it's to:

/Users/jgordon/Library/Group Containers/UBF8T346G9.OneDriveSyncClientSuite/OneDrive.noindex/OneDrive/ScanSnap

So the folder that used to be in the file system was now buried in Library but the Favorite somehow resolved to it still.

I created a shortcut to a folder of the same name as displayed in Locations/OneDrive and the path there is

/Users/jgordon/Library/CloudStorage/OneDrive-Personal/ScanSnap

Digging into OneDrive preferences it claims my location is "/Users/jgordon/Documents/One..." (yep, truncated path). This is the path OneDrive used to use, but now there's just a Favorite there.  The true path is ... yep ...

/Users/jgordon/Library/CloudStorage/OneDrive-Personal/ScanSnap 

Even though none of the files are in a location that I expect Spotlight to index it does appear to index the files stored there once I revised settings so all files were downloaded. Once I did that however the file was now readable even in the location my old Favorite resolved to: 

/Users/jgordon/Library/Group Containers/UBF8T346G9.OneDriveSyncClientSuite/OneDrive.noindex/OneDrive/ScanSnap

 So this is kind of what I think was going on to cause this particular time wasting problem

1. Apple made everyone switch to their preferred approach to managing Cloud files.
2. The folders that were once in the local file system were gone, but an old Favorite somehow resolved to a similar folder buried in a virtual file system. The file, however, was no longer resident locally, it only seemed to be available if one inspected the virtual folder with Finder. Preview could not access it because it wasn't there, and in Monterey Preview gives a misleading error message.
3. When I used the Locations OneDrive "folder" to navigate I went to a different Library CloudStorage folder where OneDrive will auto-download folders on demand. If, however, full download is active (as it was previously so I can backup but that's not the default) then even the internal system OneDrive uses has a full copy and Preview will open it.

Apple wants all Document folders to be stored in the Cloud and may eventually want all user folders in the Cloud, so part of this is probably to prevent different Cloud Providers from cross-synching folders.

I think the bug hits those very few people who had a Favorite to an old style OneDrive folder prior to upgrading OneDrive. Although these kinds of complex emergent bugs don't hit many people, there are thousands of bugs like this so sooner or later we run into them. Which is why it's now very hard for non-geeks to use a personal computer.

Managing sync issues in the Apple Notes app - what I do

I use Apple's Notes app fairly often. It's come a long way from early days but it has its share of bugs. The two I run into most often are formatting bugs and especially sync failures.

Formatting bugs seem to be related to frequent edits to a note using Notes app styles and character formats. Sometimes editing stops working in odd ways. I have to create a new Note and select all/paste into the new Note.

Sync bugs are more common and more serious. There are two kinds of sync bugs - global application sync failure and note specific failure.

Global sync means no notes are synchronizing and perhaps no iCloud content. I've seen that with iCloud password changes. I recommend never changing an iCloud password, Apple really doesn't want it to change. I had to recently because trying to use the Stanza calendar on the Saint Paul Saints web site with Apple integration triggered an instant Apple account lockout and mandated password reset (be afraid).

If iCloud sync doesn't work after a password change and iCloud seems to be properly authenticated first try restarting your iPhone or Mac. Then, on an iPhone, try sending an iCloud email. That last may require you to YET AGAIN enter your iCloud password. With luck the credential problem may resolve for all iCloud functions.

Single note sync failure may be something I see because I'm using Notes across the latest version of iOS and Mojave. I suspect it's actually fairly common even on Monterey/iOS though.

If it's just one note that won't sync between two devices you can check out Apple's web client view of Notes. That will tell you which device is off but it doesn't help with the fix. As far as I can tell there's no sync failure resolution built into Apple Notes. If Apple's sluggish iCloud sync means you have edited one note on two devices when they weren't in full sync then that particular note will no longer sync. No error messages, no offer to sort things out, no creation of two versions, it just quietly sits in isolation.

The workaround is to create a new note and confirm that syncs. Then on each separate device move the content from the now isolated notes into the new syncing note. Then delete the notes that didn't sync on each device.

Synchronization is a problem some seem to have solved (Simplenote for example), but Apple is not among this elite group.

Migration Assistant from Mojave to Monterey is mostly a train wreck

Ugh. Almost nothing went well with doing migration assistant from Mojave to Monterey. I had to trash my Photo Library and recreate a new system photo library to repopulate from iCloud. I had to turn off iCloud Drive, delete the Archive versions, then turn it back on again. A bug with deleting user accounts was unrelated but took up an hour or two.

Kind of what I'm used to with Apple to be honest.

I probably would have been better off to migrate my documents folder and my mail files manually, then recreate the rest.

Unrelated but also sad: I hoped Apple's T2 to USB-C cable would let me continue to use my T2 hub and related peripherals (some Firewire 800!) but it's unstable in early testing.

Can't empty trash because VoiceTrigger is in use: It's a macOS system integrity bug

If you delete a user account in some versions of macOS (Monterey in my case) where the user account was created in certain earlier versions of macOS you will run into a System Integrity bug.

There's a folder called VoiceTrigger that in the deleted user account that is protected by System Integrity (~/Library/VoiceTrigger/SAT. ) It's located in the User's Library, so it should not be SIP protected. (In Monterey there's nothing there called SAT).

I'm guessing the bug is that it was never supposed to be SIP protected but in some version of macOS it was. Maybe Big Sur. (There's a second bug because the error message is incorrect. The problem isn't that the file is in use, the problem is it's SIP protected.)

I found the fix in in r/MacOS - disable SIP, delete, re-enable SIP:

Disable System Integrity Protection

1. Click the  menu.

2. Select Restart...

3. Hold down Command-R to boot into the Recovery System.

4. Click the Utilities menu and select Terminal.

5. Type csrutil disable and press return.

6. Close the Terminal app.

7. Click the  menu and select Restart....

Login normally, then Empty the Trash Can

Re-Enable System Integrity Protection

1. Click the  menu.

2. Select Restart...

3. Hold down Command-R to boot into the Recovery System.

4. Click the Utilities menu and select Terminal.

5. Type csrutil enable and press return.

6. Close the Terminal app.

7. Click the  menu and select Restart....

Things other's suggested that didn't work:

1. Terminal: sudo rm -rf ~/.Trash/*

Note you need to be admin to do this. There's a way to escalate non-admin to use sudo but I think Apple has basically given up on non-admin user accounts.

2. Turn off iCloud document sync.

When iCloud Keychain stops working (No more Safari passwords) - Mojave

I'm buying tickets for an event and suddenly there's no password autocomplete in Mojave Safari. Safari Preferences Passwords shows 3-4 entries, but my Apple passwords shows on my iOS devices and my Monterey Air. It's just Mojave that has lost all its iCloud/keychain access.

A good reminder that if you want to use Apple Passwords as a 1Password replacement you need to export a static backup (and this must be automated). The Cloud is where data goes to die.

A found a relevant 2016 Apple Discussion post which would be Mojave era. So I wonder if it's a Mojave bug. The fix there was from "Linc Davis" a "Level 10" with 209K points [1]

Please take these steps to resynchronize the iCloud keychain. Your keychain on iCloud and your other Apple devices won't be affected. Take Step 2 only if Step 1 doesn't solve the problem.

Step 1

Back up all data.

Open the iCloud pane in System Preferences and uncheck the Keychain box. You'll be prompted to delete the local iCloud keychain. Confirm—the data will remain on the servers. Then re-check the box. Follow one of the procedures described in this support article to set up iCloud Keychain on an additional device. Test.

Step 2

If you still have problems, uncheck the Keychain box again and continue.

Triple-click the line below on this page to select it, then copy the text to the Clipboard by pressing the key combination  command-C: 

~/Library/Keychains

In the Finder, select

          Go ▹ Go to Folder...

from the menu bar and paste into the box that opens by pressing command-V. You may not see what you pasted because a line break is included. Press return.

A folder named "Keychains" should open. Inside it is a subfolder with a long name similar to (but not the same as) this:

           421DE5CA-D745-3AC1-91B0-CE5FC0ABA128

The above is only an example; yours will have a different name of the same general form. Drag the subfolder (not the Keychains folder) to the Trash.

Restart the computer, empty the Trash, and re-enable iCloud Keychain.

Toggling Keychain off and on didn't seem to do anything so I figured I'd check in the morning. Before I checked though I did review my passwords in Monterey. For *reasons* (this happens way too often) I had to reenter my iCloud credentials there but I was also asked the usual iCloud keychain questions -- provide passcodes for my other machines.

Then I looked at my Mojave machine and Safari had my passwords again.

Maybe the fix was toggling Keychain and waiting a bit, but I'm suspicious that something happened somewhere in iCloud that required me to do the iCloud Keychain authentication dance from a Mac -- and Mojave couldn't do it.

Again, if you use Apple Passwords as your sole repository you need a non-iCloud backup.

- fn -

[1] No profile info, has participated in 97K threads. Either insane or an Apple staff pseudonym.

Relentless beeping when plug iPhone into MacBook USB port: reset iPhone Location and Privacy

Solved 9/12/2022

I wrote the post below when I used an iPhone 8. When I went to an iPhone 13 it seemed to resolve, but today I tried charging my iPhone from my Air and it was beeping again.

I didn't have time to waste so I switched to a normal charger, but later it occurred to me that there might be a way to reset the trust relationship.

There is, but it's not on the iTunes side. It's on the iPhone side.

If you don't want to trust a computer or other device anymore, change the privacy settings on your iPhone, iPad, or iPod touch. Go to Settings > General > Transfer or Reset [Device] > Reset > Reset Location & Privacy. Now when you connect to formerly trusted computers, the Trust alert will ask you whether you trust that computer. 

I did the reset on my iPhone and next time I plugged it in to my Mojave Air I got the "do you want to trust" dialog. I accepted it and now the phone charges without beeping. I suspect the problem will recur based on the notes below however.

--

When I plug my iPhone 8 into my MacBook Air's USB port I get relentless beeping and the iPhone power icon flashes. Sometimes iTunes throws up a "received an unexpected response" error. I'm on Mojave iTunes.

I figured this was a bad USB cable or bad port or bad connection, but it's both ports and all cables and the phone connection is good. More importantly, I rebooted with no peripherals connected and switched to my admin account. Then every beep was associated with a new iTunes dialog asking me (yet again, and again, this is such a pain) to authenticate. When the dialogs ended the beeping stopped.

Stack Exchange has an article on this, but that's definitely connection issue related. This Apple tech article seems closest; but they also focus on cable issues.

I'm not entirely sure it's not something hardware related on my Air, but I think there's an iTunes component too.

The console shows:

I see: usbmuxsd errors, HandleUSMMuxConnect, iTunes Helper, MobileDeviceUpdater, "no such device". So iTunes is causing the beeps (though the underlying issue could be hardware).

From those clues I found these posts:

• https://discussions.apple.com/thread/251691536: kill usbmuxsd related processes
• https://discussions.apple.com/thread/6611777?answerId=27079314022#27079314022 - a bug in usbmuxsd that Apple may have fixed in later releases
• https://discussions.apple.com/thread/6728641?answerId=6728641021#6728641021 has a discussion:

It's an iTunes 12 bug... Not sure who's responsible for usbmuxd at Apple, but they should be fired! This was extensively discussed and worked out here: itunes 12 will not recognize iphone

All credit to oskapt, who's post detailed the entire issue. The short version is a recent version of usbmuxd has a programming error that leads it to never close any connection. At the same time, it's constantly making new connections too. The end result is this background process actually hits the built-in UNIX limit on open connections by a single process (to prevent bugs like this from ultimately crashing an entire computer), and is blocked by design from functioning after that point. Once usbmuxd fails, iTunes can't see your iOS devices.

The fix is to quit usbmuxd, either via Activity Monitor or Terminal. It will automatically relaunch, and work again until it hits the limit. That thread has several suggestions for automated scripts to run every 24-48 hours to prevent this.

Update 2/20/22: I never solved this problem, but I did get a new phone and the beeping is gone. So either a connection problem with the old iPhone or a bug with the "trust relationship" between iPhone and MacBook.

Update 3/5/2022: In the process of cleaning out old iPhones I tried various iPhones and I tried iPhones that beeped on my Mojave iTunes machine on a different machine. I think it's a bug with establishing a Trust relationship. Probably fixed in later versions of iTunes.

Fixing the Mojave Mail split view in full screen bug

For many users Mojave email will periodically open in Split View mode even then Mail Preferences: General split view is unchecked.

I'm trying this fix:

1. Check Mail Preferences:General "Prefer opening messages in split view when in full screen". Confirm Mail opens in split view. Maybe quit and restart.
2. Now open mail preferences and uncheck that option and force quit Mail. (Somewhere in the Mojave era or earlier macOS preferences got wonky such that an app on exiting could do weird and occult things to preferences.)
3. Restart mail with Safari open in full screen and confirm you don't get the Split View -- get Mail as full screen.

Works so far but I wouldn't be surprised if fix doesn't last.