QRecall 3.0.5.1 on MacOS Sonoma

Hi James,
I hope you're keeping well. Since moving to MacOS Sonoma (new Mac came with it) and QRecall 3.0.5.1 I've noticed two phenomena I can't quite explain and would like to ask your council.

0) background
My QRecall archives and stacks live on APFS volumes connected via iSCSI, physically being hosted on a NAS box in my office and another in my home (stacks are VPNed in). This seems rock solid, I have my Photos library, Music library and client projects on such volumes and especially the latter are doing some crazy i/o at times but never fail. MacOS knows they're not truly local volumes but treats them as such for all practical purposes.

Before moving Macs, OS versions and QRecall versions (I'm so sorry about that, I know that's nigh impossible to debug and I should have tried to move one change at a time) all QRecall actions ran like clockwork.

1) "permissions" issue
Every now an then an action will fail saying "archive package does not have modify access" (/Volumes/QRecall02/something.quanta for example). Once this happens, no scheduled action will work on that archive until I run a quick

qrecall repair something.quanta/ --monitor --options noautorepair,correct

which fill fix the issue, but sometimes only for one or a few actions before the problem comes up again.

The files and directories are mine (user 501), they have all the permissions they need and I'd never wittingly change them. Currently they co-belong to the group "staff", I'm open to changing that to "wheel" or "admin" or anything if it can help. But why does this issue crop up in the first place? The repair action doesn't make any changes to permissions that I can detect.

2) all Stacks are "undead" now
All scheduled actions that try to cascade to or audit a stack don't work anymore. They all say: "stack is not defined" "id: (nil) Expected: <some uuid>". This is true even when I create a completely new audit action and choose the archive by hand (not recent list) and pick a stack from the dropdown list the action editor filled for me with the stacks it knows actually exist. Running that action via schedule or via "run immediately" will consistently not work.

But: opening an archive I can see the stack(s) in the sidebar, and I can manually cascade to a stack or audit it just fine.

Is there anything I can try to fix this on my end?

Best of regards,
Olfan

Olfan wrote:1) "permissions" issue
Every now a then an action will fail saying "archive package does not have modify access" (/Volumes/QRecall02/something.quanta for example). Once this happens, no scheduled action will work on that archive until I run a quick
qrecall repair something.quanta/ --monitor --options noautorepair,correct
which fill fix the issue, but sometimes only for one or a few actions before the problem comes up again.

That is an odd one. One of the things that might help is, as soon as it happens again, send a diagnostic report. (Help > Send Report in the QRecall application.) This will upload recent log activity as well as the state of your archives, which might provide some clues.

Spoiler alert: anytime something goes wrong, I'm going to suggest you send a report.

2) all Stacks are "undead" now
All scheduled actions that try to cascade to or audit a stack don't work anymore. They all say: "stack is not defined" "id: (nil) Expected: <some uuid>". This is true even when I create a completely new audit action and choose the archive by hand (not recent list) and pick a stack from the dropdown list the action editor filled for me with the stacks it knows actually exist. Running that action via schedule or via "run immediately" will consistently not work.

Also very strange, but here's what you can try:

First, disconnect the stack from the archive:

Open the archive in QRecall

Show the stacks sidebar

Hold down the Shift + Control + Option keys while clicking on the action menu to the right of the stack. Choose "Disconnect..."

This erases the stack configuration in the archive without destroying the stack container.

Now, reconnect the stack to the archive:

Open the archive in QRecall

Hold down the Option key while choosing New > Reconnect Stack... in the main menu.

Now enter, setup, or choose the same stack container you had before.

If all goes correctly, the archive and stack will be reconnected.

Now open each stack action and make sure the correct stack is selected.

Let me know if that helps. And if if doesn't, send another diagnostic report...

Quick update on the stacks issue:

I could not make a "Disconnect" option appear. Holding the Option key changes the "Delete" to "Reconnect", also holding down Cmd and/or Shift doesn't do anything further.
I did manage to remove the stack's association to the archive by moving it into a hidden directory and chmod'ing that directory to 000, though, and then trying to delete it. The archive lost its connection to the stack but couldn't actually destroy it.
Reconnecting the stack after putting it back into place worked fine. Checking the cascade scheduled action seemed okay, running it wouldn't work, though.
I then edited the Cascade action to no stack, saved, then edited it again to the stack I wanted, saved, ran, no luck.
Still, the stack can be updated from within the archive through the »Layers«->»Stack slices« menu and audited via the sidebar.

Looking at the action plist using plutil -p does point to the correct stack guid, it is the same guid as found in both the ~Libraries/Preferences/QRecall/Stacks/ folder and the archive folder as <guid>.qrstackconfig.
I did notice that the qrstackconfigs in the archive and in the Stacks prefs folder differ in many places but couldn't see what the differences mean.
Some experimentation changing the case of the guid (which is mostly uppercase in the plists and lowercase in the filesystem) didn't show any success. My APFS volumes are case-insensitive anyway so I didn't expect anything there, but changes to the plists didn't have an effect either. Can't see why it gets a nil instead of the guid that's there.

Olfan wrote:I could not make a "Disconnect" option appear. Holding the Option key changes the "Delete" to "Reconnect", also holding down Cmd and/or Shift doesn't do anything further.

Not Command, Control.

Option+Control changes to "Delete" to "Disconnect...", ... but you figured it out

Checking the cascade scheduled action seemed okay, running it wouldn't work, though.

This also isn't making any sense, since both the action and the interactive command end up doing the same thing: launching a background instance of QRecallHelper to preform the action.

I'm also seeing really anomalous messages in your log, like this one:

unreadable sequence file; using legacy sequence

Which makes no sense because this file gets recreated during the repair and is readable by the user.

So I have to suspect that there's some strangeness(™) going on with the storage device and/or the security framework.

I have two suggestions.

First, make sure there are no restrictions on QRecall by going to the System Settings > Privacy & Security > Files and Folders. Find the various QRecall component (particularly QRecallHelper) and make sure everything is enabled. (Alternatively, add QRecallHelper to the Full Disk Access category.)

Second suggestion is, if the QRecall02 volume is only used for QRecall archives, select the volume in the Finder, choose Get Info, and at the bottom check "Ignore ownership on this volume".

I did notice that the qrstackconfigs in the archive and in the Stacks prefs folder differ in many places but couldn't see what the differences mean.

UUIDs are case insensitive, pretty much everywhere in QRecall.

Can't see why it gets a nil instead of the guid that's there.

It would appear that it can't read the file, just like the regular actions can't read the sequence.index, neither of which makes any sense.

And if you try any of these suggestions, please follow up with another diagnostic report. Thanks!