Mac: “Text file → Tag” freezes with ~130k mappings + recurring “Can’t access file via secure bookmark”

Mac
1

Environment

  • Mp3tag for Mac: 1.9.10 (build 126)

  • macOS: Tahoe 26 on Apple Silicon

  • Storage: Local APFS SSD (/Users/neo/Music/JRiver/Music)

What I’m trying to do
Bulk‑write Catalog Number to my library by mapping path → fields via Actions → Text file → Tag using the format string:
%_path%|%CATALOGNUMBER_RAW%|%CATALOGNUMBER%
Example input lines (piped values):
/Users/neo/Music/JRiver/Music/U2/Achtung Baby (Catalog #_ Unknown)/01 Zoo Station.flac|546 928-2|1991 Universal - 546 928-2
/Users/neo/Music/JRiver/Music/Jay-Z;Paul Nice/The (Unofficial) Black Album Remix (Catalog #_ Unknown)/02 December 4th (Paul Nice Remix) (Edit).flac|None|Catalog #: Unknown

Issue 1 — UI freeze with large paste

  • I select ~130,000 tracks, open Text file → Tag, choose Paste text, and paste ~130k lines.

  • The dialog and app beachball and become unresponsive (eventually “Application Not Responding”). Force Quit is required.

  • Question: is there a practical or documented limit for number of selected files and/or pasted lines on macOS? Any guidance on safe batch sizes (e.g., 5k, 10k, 20k) or a streaming/line‑by‑line import mode?

Issue 2 — “Can’t access file via secure bookmark”

  • When I try Text file → Tag → File… and point to /Users/neo/Downloads/mp3tag_catalog_formatted.txt, I get:
    Cannot access file "/Users/neo/Downloads/mp3tag_catalog_formatted.txt" via secure bookmark

  • I also see the same error when saving tags to some audio files, e.g.:
    Cannot access file "/Users/neo/Music/JRiver/Music/10,000 Maniacs/Blind Man's Zoo (Catalog #_ Unknown)/01 Eat for Two.flac" via secure bookmark

  • I already tried the forum‑suggested reset (Mp3tag closed):

    defaults delete app.mp3tag.Mp3tag SecurityScopedBookmarks

    Then I reopened via ⌘O on the top‑level folder to re‑grant access. The error still reappears in my workflow. (This command was suggested by Florian in “Can’t access file via secure bookmark”.)

Steps to reproduce (freeze)

  1. Open library root via ⌘O.

  2. Select ~130k files.

  3. Actions → Text file → Tag → Paste text.

  4. Paste ~130k lines (path|CATALOGNUMBER_RAW|CATALOGNUMBER).

  5. Observe beachball / freeze.

Steps to reproduce (secure bookmark)

  1. Actions → Text file → Tag → File….

  2. Choose a .txt in ~/Downloads (or ~/Music).

  3. Error: “Cannot access file … via secure bookmark”.

  4. After defaults delete … SecurityScopedBookmarks and reopening the folder, error still occurs in bulk writes.

What I’m asking

  • Recommended upper limits or best practices for Text file → Tag on macOS (selected files and pasted lines).

  • Whether the paste dialog loads all lines into memory (and if so, any planned streaming/virtualization).

  • Guidance on permanently resolving the secure bookmark error for both file‑based imports and bulk tag writes (beyond deleting stored bookmarks), including any known edge cases with opening via Finder’s Services vs ⌘O.

Happy to provide a small sample mapping file, a sysdiagnose, and screen recordings if helpful.

2

Thank you for the deatiled reports!

I think the Text to Tag function is currently not useable for the amount of files and lines you're working with. Even with 5K lines, there is a significant UI freeze, while Mp3tag tries to split the pasted text into separate lines. I've made a note on my internal list and will try to improve this with an upcoming version.

As for the secure bookmarks issue: did you try opening your home directory via ⌘O and then ⇧⌘H to prevent future issues? You can also cancel the reading process, because it would probably take some time.

3

Hi Florian. Quick follow‑up with new data after re‑trying your suggestions.

Status after re‑granting access via ⌘O → ⇧⌘H

  • Unfortunately this didn’t improve general access. Roughly 90,000 tracks in my library still fail with “Cannot access file … via secure bookmark” when I try to write tags or import in any amount. This matches the same error text shown in my original post.

Regression since macOS Tahoe

  • I want to flag this as a regression on my machine: before updating to macOS Tahoe 26.0 I was able to import and tag the full selection (~130,000 files) using the same library path and workflow. Since updating, the secure‑bookmark error appears during the same bulk operation. Nothing else in my storage layout or file locations changed.

Repro (current builds & setup)

  • App / OS: Mp3tag for Mac 1.9.10 (build 126) on Apple Silicon; macOS Tahoe (26).

  • Library: local APFS SSD at /Users/neo/Music/JRiver/Music.

  • Steps:

    1. Open the library root via ⌘O (as recommended).

    2. Select ~130k files.

    3. Start Text file → Tag (either Paste text or File…).

    4. I get the error “Cannot access file … via secure bookmark” and are skipped; net effect is ~90k inaccessible.

  • I also re‑tried the forum reset (defaults delete app.mp3tag.Mp3tag SecurityScopedBookmarks, app closed).

I’ve tried two other ways to open my library:

  1. Inside Mp3tag (File → Open… → ⇧⌘H → Home)

    • I reset saved permissions, reopened, granted access to Home, then opened my music root.

    • When I run Text file → Tag (Paste or File…) I still hit “Cannot access file … via secure bookmark” on a very large subset — roughly 90,000 tracks are blocked even in 1–3K selections.

    • This is a regression since updating to macOS Tahoe; the same bulk workflow worked for me before the update.

  2. Finder extension (“Open with Mp3tag”)

    • My library has ~239,000 songs. Using the Finder extension to open that scope causes macOS to show: “Your system has run out of application memory.” The hand‑off fails before Mp3tag can load the selection.

    • So the Finder route isn’t a viable workaround at this size either.

Net result

What would help me troubleshoot with you

    1. Please give me a test version that logs what’s going on with permissions.
      In other words: when Mp3tag can’t touch a file, I’d like a log that says which path it tried, what permission it used, and why macOS said no. I’ll run it and send you the logs.
    2. Tell me if the newest macOS changed anything that affects this.
      Did “Tahoe” tighten rules around file paths, aliases/symlinks, or case sensitivity so that opening my Home folder no longer covers everything underneath? If so, what should Mp3tag do differently?
    3. Confirm how Text‑to‑Tag handles permissions during big writes.
      When writing lots of files, does Mp3tag stick with the single permission for the parent folder, or does it switch to per‑file permissions (which might fail under load)? Knowing this would explain why many files get blocked while others succeed.
    4. If Mp3tag hits a path it can’t access, please show a “Grant access to this folder” prompt.
      That way I can fix the permission on the spot instead of having files silently skipped.

Happy to provide: a small mapping sample, a short screen recording, and sysdiagnose taken during a failing run. Thanks again for looking into both the Text‑to‑Tag scaling and the bookmarking behavior—please let me know what data would be most useful to you next.

4

It looks like you already did all the steps that usually resolve the secure bookmarks issue.

I've just tested this with 150.000 files (loading, import via Text File to Tag) and did not run into any issues. The contents of the text file are correctly imported and saved to the files. At the moment, I don't think that there is a regression with macOS Tahoe.

The current version already logs any errors via os_log. Those are visible via Console.app when set to streaming or, more conveniently, via BackLog, which is a tool that can gather logs already stored on your Mac that can give more detailed insights into what might be causing an issue. You can set the process to Mp3tag and include all events not directly created by this binary.

Mp3tag already asks for permission if it encounters a path where no secure bookmark is stored (or no secure bookmark for a parent folder is stored). The error only occurs if secure access cannot be granted despite the existence of a secure bookmark.

Every file access is enclosed in a pair of startAccessingSecurityScopedResource() and stopAccessingSecurityScopedResource(), as required by secure file access.

You could double-check via
defaults read app.mp3tag.Mp3tag SecurityScopedBookmarks
and see if the path in question really is part of the secure bookmarks.

5

Thanks for checking this, Florian. I’m still running into the same two issues I described earlier: when I paste roughly 130,000 lines into Text File → Tag the app becomes unresponsive and eventually needs to be force‑quit, and when I use Text File → Tag → File… (or save tags on some audio files) I get “Cannot access file … via secure bookmark.”

I repeated the permissions steps you suggested (open the home folder via ⌘O and then ⇧⌘H) but the secure‑bookmark error still appears in my workflow.

Per your recommendation I ran the Terminal check. The command “defaults read app.mp3tag.Mp3tag SecurityScopedBookmarks” returns an empty dictionary on my system: {}. That seems to indicate there are no stored bookmarks for Mp3tag even after reopening the top‑level folder. I can also add that trying the Finder “Open in Mp3tag” route with my full 242,000‑song library throws a “Your system has run out of application memory” dialog.

To help you see exactly what’s happening I’m attaching a link with a Console log capture taken while the error appears (process filtered to Mp3tag), the exact mapping text I’m using (mp3tag_catalog_formatted.txt), and the full output of the Terminal bookmark check above. For reference, mp3tag_catalog_formatted.txt contains lines in the form “path|CATALOGNUMBER_RAW|CATALOGNUMBER” as already discussed.

If there’s anything else you want me to capture, let me know and I’ll add it.

https://u.pcloud.link/publink/show?code=kZ0QNe5ZR2rWNSaSXlmbsEpUJIniLyYOmrB7

6

Thank you for the logs!

From what I can see, Mp3tag tries to create a secure bookmark for a file inside /Users/neo/Music/JRiver/Music/ which fails.

2025-10-01 23:53:28.845021-0600  localhost Mp3tag[18529]: [app.mp3tag.Mp3tag.BookmarkService:MTFileBookmarkService] Error creating secure bookmark from <private>: Error Domain=NSCocoaErrorDomain Code=256 "Could not open() the item" UserInfo={NSURL=file:///Users/neo/Music/JRiver/Music/2Pac/Nu-Mixx%20Klazzics%20(Catalog%20%23_%20Unknown)/01%202%20of%20Amerikaz%20Most%20Wanted%20(Nu-Mixx%20Remix).flac, NSDebugDescription=Could not open() the item}

Normally, when a secure bookmark is acquired for a top-level folder (e.g., /Users/neo/Music/), Mp3tag doesn't need to create any new bookmarks. From the log, it looks like you're selecting individual files and not the folder only. Can you double-check that no files are selected when you choose Open via ⌘O?

Is this the case also after quitting Mp3tag?

7

Hi Florian,

Thanks for taking a look and for the pointers. This is Audible subbing in for my AI to add some clarity and humanity to this conversation.

I’ve tried about every variation for loading the folder including dragging and dropping, clicking ‘Open’ or ‘Add’ from the ‘File’ dropdown, fetching every individual track via Finder (which doesn’t work because finder crashes when it tries to load everything), etc. I’m able to drag the 140,000 files I want to edit from JRiver into mp3tag but without the bookmarks I can’t edit anything. To confirm your question: I’ve tried only the top‑level folder via ⌘O (no files selected):

/Users/neo/Music/JRiver/Music/

When I do this, Mp3tag begins loading the entire library (~230,000 files) and crashes around ~140,000 as the application memory climbs to ~125 GB. Because the open action never completes, I can’t get through the process to establish the bookmark that way and therefore I can’t update the metadata for ~90,000 files.

Regarding the Terminal check: initially,
defaults read app.mp3tag.Mp3tag SecurityScopedBookmarks
returned {}. After quitting Mp3tag and running it again (after it started loading the top level folder, which I just cancelled), it now shows a stored bookmark for the folder:

{   "/Users/neo/Music/JRiver/Music" = {length = 708, bytes = 0x626f6f6b c4020000 00000410 30000000 ... 04000000 00000000 }; 

}

If there’s a way to add/confirm the folder bookmark without triggering a full scan or to defer indexing until after the bookmark is established, I’m happy to try it. I can also provide fresh logs if helpful.

Thanks again for your continued support,
Audible

8

This looks correct. You should now have secure access to all files inside of

/Users/neo/Music/JRiver/Music

A quick check would be loading one subfolder with a small subset of files and performing a write operation (e.g, saving a tag). If this works, you could tackle the whole set of files in 3 or 4 batches.

9

Hey Florian,

I just loaded the files that I’m trying to edit metadata for from JRiver to mp3tag. It’s still not allowing me to properly “load” the files and so none of my metadata is showing for ~90,000 files and when I try to edit the metadata I’m still getting the secure bookmark error.

10

What about the first part of the test I’ve outlined above? Does it work if you load the files from within Mp3tag?

11

I tried the first part of the test you outlined and still found that the folder I loaded didn’t show the metadata and didn’t have a secure bookmark.

I don’t know if it would be possible to load the files from within mp3tag because the files have been isolated in JRiver and are spread across about 16,000 folders. The folders are tagged with the catalog number but I don’t know how I would proceed from there. Would mp3tag batch load 16,000+ folders if I searched by the catalog number (which in this case would be “Catalog #: Unknown”) from the Command+O window and then opened them all at once?

12

If loading a subfolder with only a couple of files from the folder in secure bookmarks still produces errors for you, I’m currently out of ideas. This is something that should work without any problems.

It also means that any attempt at working with more files from more folders, or even opening the files from another app like JRiver will also fail.

If I have any other idea of what to try, I’ll reply here.

13

Can you please try the following:

  1. Create a playlist from the files you want to edit via JRiver.
  2. Export the playlist to an external .M3U file via Export Playlist... from the playlist's context menu in JRiver.
  3. Load this playlist file via File → Open... in Mp3tag.
  4. Perform the import via Convert → Text File - Tag using a text file for import.

Please ensure that in this session with Mp3tag, you don't drag any files from JRiver to Mp3tag.

14

Hey Florian, I found an alternative solution through the command line but would also like to fix mp3tag so that I can use it in the future. Do you know how I can fix it so that I don’t run into the secure bookmarking error again?

15

My guess is that the source of the problem is a long-standing bug in macOS, where the sandbox imposes an unspecified limitation on the number of files that can be opened by a user.

This happens when individual files are opened in Mp3tag via File → Open… and also when files are dragged and dropped from another app. After what seems to be a “magic” number of files (around 3000 in my tests), the sandbox stops loading any more files. Any other operation that attempts to load files will then fail.

This is exactly what you observed when loading the text file to import also failed.

The details of this macOS bug are described here:

An example project that demonstrates the issue is available here:

To reproduce the issues you’re experiencing, I first loaded 300,000 files into Mp3tag and tried Convert → Text File - Tag, which worked without any problems. After that, I installed JRiver and imported the 300,000 files. I then dragged a subset of files to Mp3tag (starting with 150,000 and reducing the number with each iteration). This is when I reproduced the sandbox error, which made the app unusable in each failed session.

It's worth noting that the issue is triggered even before the list of files reaches Mp3tag, so it's not possible to workaround from inside of Mp3tag. Instead, loading of files should preferably happen on the folder-level, or via playlists — which brings me to the workaround for your initial task.

To work around the issue, I tried to find a method that doesn’t involve dragging and dropping from JRiver or opening individual files (since that would trigger the macOS sandbox limitation again). I came up with the playlist export I described in post #13, which works without any problems — even for the complete set of 300,000 files. There, Mp3tag can examine each of the file paths in the playlist, check the existing bookmark (the one on the root of the music library), and use it to open the file via sandboxed secure access.

I also reproduced the freeze when pasting large amounts of text using the text-box–based version of the converter. Contrary to my initial assumption in post #2, Mp3tag isn’t simply taking too long to split the lines. Instead, the macOS text control I’m using (NSTextField) is simply not suited for handling such large amounts of text. I’ll fix this in an upcoming release.

16

I've now fixed the freeze when pasting large amounts of text using the text-box–based version of the converter with Mp3tag for Mac v1.9.11.

I'm marking the previous post as solution to this topic.