StartScreen should be StartCenter, sorry, momentary lapse of terminology.

This is repeatable both on my macmini Catalina 10.15.6, and MacbookPro Catalina 10.15.6

That is not a new problem, it has always happened that occasionally some of the files remembered in the Start Centre won't open if you click on them. It has to do with how LibreOffice stores the rights to access them between sessions as so-called security scope bookmarks. This is the first time a bug has been reported for it, though.

In detail: A sandboxed process does not have access to the user's files or directoress even if it would know the pathnames. Normally the only way for a sandboxed process to get access to a file that is not in its own app bundle or in some specific open locations like the temp directory is when the user chooses it in the file chooser, which runs as a separate process outside the sandbox. (This is all handled though the system APIs.)

To be able to access the same file again later, another time the same program runs, the process creates a security scoped bookmark for the file and stores that in its settings ("defaults"). When the same program then later wants to access the same file it uses that security scoped bookmark. Occasionally this for some reason fails.

Can you come up with a way reproduce the problem repeatedly? Open an existing file in LibreOffice Vanilla, quit LibreOffice Vanilla, start it again, and then try to open the file from the Start Centre and it fails? That would be very useful. If not, it is very hard to debug the problem.

Did you do something special on your machine when this started to happen, like clean out your "defaults" for the domain com.collabora.libreoffice-free? (I don't mean LibreOffice's so-called "profile".) Check with the command:

defaults read com.collabora.libreoffice-free | less

You should see a list of things like:

"bookmarkFor:file:///Users/tml/Documents/AAAHelloThere.rtf" = {length = 764, bytes = 0x626f6f6b fc020000 00000410 30000000 ... e0010000 00
000000 };

which is the security scoped bookmark for a file that is remembered and can be opened without going through the file chooser.

If there is no such an entry for a file that still is listed in the Start Centre, LibreOffice Vanilla won't be able to open it.

(Oh, and to make it clear: I could not reproduce it on my Mac running 10.15.6. Both files that happened to be in the Start Centre from I don't know when did open, and when I tried with a new file, it worked too.)

The code for the handling of those security scope bookmarks is in sal/osl/unx/uunxapi.cxx, look for "bookmarkFor".

@Tor : thanks for the information.

I ran the command you listed, and it gives 3 entries from my Downloads folder, with the rest being some paths in /var/folders and a seemingly obfuscated sequence of characters.

Of those that are clearly readable, i.e. those from the Downloads folder, only 1 entry appears in, and is openable from, the StartCenter (a Base file).

The two other files listed are not visible in the StarCenter, but one is nonetheless present in the filepath, and the other one isn't. None of these 2 files has an thumbnail icon in the StartCenter.

The thumbnails in the StartCenter that are no longer in the place where they when opened once before display a normal message when attempting to load the document of "This document is not available." (which is true, as I've moved the file elsewhere).

The thumbnails displaying the access refused message link to files that are still in the same place as when they were last opened, and most of these do not appear in the list provided by the default read command you gave.


Not sure that helps much with moving further with this.

I've not changed anything in my LOVanilla setup that I can think of, just the usual let the AppStore automatically install any updates.

OK. If you can come up with a way to consistently make the problem happen, please tell here. Otherwise there is not really much I can do.

It is a bit strange that only three entries for "real" documents appear in your list of security scoped bookmarks. Have you not used LibreOffice Vanilla much?

(The /var/folders/hex ones are temporary files that presumably it should not even be necessary to store there. That they still get stored is a minor bug, there should ideally be a way to know if a file is being created that won't be needed by future instances of the program.)

I assume that this bug happens if you open or create a file (using the file chooser to select where) but for some reason the corresponding security scoped bookmark is not created and not stored in the defaults.

(Additional code pointer: fpicker/source/aqua/SalAquaFilePicker.mm)

(Also, note that this code related to a sandboxed LO is quite old, from 2013, so I don't remember much details abot it.)

(In reply to Tor Lillqvist from comment #7)
> OK. If you can come up with a way to consistently make the problem happen,
> please tell here. Otherwise there is not really much I can do.
> 
> It is a bit strange that only three entries for "real" documents appear in
> your list of security scoped bookmarks. Have you not used LibreOffice
> Vanilla much?

On that particular machine (macmini2014), no I don't use Vanilla much, it is more often than not running dev versions. 
On my MBPro, where I use Vanilla pretty much every day, there is a much longer list.

I don't seem to be able to reproduce this any more, so should we close it as INSUFFICIENT DATA ?

Whoops !
I've just reproduced this on

Version: 7.0.3.2
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded


with an ODB file that I had opened previously in LO (non-vanilla), and then subsequently in Collabora Office.

When I attempted to open in LO Vanilla from the StartCenter to test comparative behaviour, I get an "Access Refused" error message.

Alex, so is this what happened?

- Initially, the document in question does not appear in the Start Centre in TDF LibreOffice and not in the Start Centre of LibreOffice Vanilla either. This is important to check, in order for this test to be relevant.

- You open the document in TDF LibreOffice, and then quit it.

- If you run TDF LibreOffice again, the document (naturally) shows up in Start Centre, and it opens if you click on that. Quit TDF LibreOffice again.

- Now you run LibreOffice Vanilla. The document appears in that StartCentre, too (but does not open). That is appears here would be a bit surprising.

I had thought that LibreOffice Vanilla uses a separate "profile" directory than the non-sandboxed TDF LibreOffice and that thus the list of recent files is separate, too. But if the above happens, they apparently share the list, but then LibreOffice Vanilla does not have access to files that have been opened earlier only in TDF LibreOffice.

Another possibility is that the profiles (including the list of recent documents) are separate, as expected, but if you edit a document in LibreOffice Vanilla, and save it, LibreOffice Vanilla saves the security-scoped bookmark for it. If you then open the same document in TDF LibreOffice, and then save it, the security-scoped bookmark for the file that LibreOffice Vanilla has stored is no longer valid, because it is in a sense no longer the same document. It might have the exact same pathname, but when you have saved it inbetween in another app (TDF LibreOffice), the file has actually been removed and a new file with the same pathname created. Thus it is actually a different file.

Anyway, the solution to the problem would probably be to make sure in a sandboxed LibreOffice to ignore entries in the recent documents list that can't be accessed anyway. Not much code is needed for that. Then the Start Centre would not show documents that aren't actually openable from it.

(In reply to Tor Lillqvist from comment #12)
> Alex, so is this what happened?
> 
> - Initially, the document in question does not appear in the Start Centre in
> TDF LibreOffice and not in the Start Centre of LibreOffice Vanilla either.
> This is important to check, in order for this test to be relevant.
> 
> - You open the document in TDF LibreOffice, and then quit it.
> 
> - If you run TDF LibreOffice again, the document (naturally) shows up in
> Start Centre, and it opens if you click on that. Quit TDF LibreOffice again.
> 
> - Now you run LibreOffice Vanilla. The document appears in that StartCentre,
> too (but does not open). That is appears here would be a bit surprising.
> 


Yes, it certainly seems to be very similar to what you describe as the scenario.
Needs confirmation from my side.



> I had thought that LibreOffice Vanilla uses a separate "profile" directory
> than the non-sandboxed TDF LibreOffice and that thus the list of recent
> files is separate, too. But if the above happens, they apparently share the
> list, but then LibreOffice Vanilla does not have access to files that have
> been opened earlier only in TDF LibreOffice.
>


Looking at this just now, the profiles aren't shared, at least the list of recent documents is different between the two applications.



> Another possibility is that the profiles (including the list of recent
> documents) are separate, as expected, but if you edit a document in
> LibreOffice Vanilla, and save it, LibreOffice Vanilla saves the
> security-scoped bookmark for it. If you then open the same document in TDF
> LibreOffice, and then save it, the security-scoped bookmark for the file
> that LibreOffice Vanilla has stored is no longer valid, because it is in a
> sense no longer the same document. It might have the exact same pathname,
> but when you have saved it inbetween in another app (TDF LibreOffice), the
> file has actually been removed and a new file with the same pathname
> created. Thus it is actually a different file.

I'll check this scenario as well.

(In reply to Tor Lillqvist from comment #12)


> Another possibility is that the profiles (including the list of recent
> documents) are separate, as expected, but if you edit a document in
> LibreOffice Vanilla, and save it, LibreOffice Vanilla saves the
> security-scoped bookmark for it. If you then open the same document in TDF
> LibreOffice, and then save it, the security-scoped bookmark for the file
> that LibreOffice Vanilla has stored is no longer valid, because it is in a
> sense no longer the same document. It might have the exact same pathname,
> but when you have saved it inbetween in another app (TDF LibreOffice), the
> file has actually been removed and a new file with the same pathname
> created. Thus it is actually a different file.


Could not reproduce the issue in the above scenario.

1) Created new Calc file in LO Vanilla. File not previously present on system.
2) Made some changes to file. Saved.
3) Shut down LO Vanilla completely
4) Started LO TDF
5) Drag and dropped previously created Calc file onto running LO TDF
6) Made some changes to file, saved and quit.
7) Restarted LO Vanilla - Calc file reference/icon shows in StartCenter.
8) Click on Calc file to load into LO Vanilla
9) No error message, file loads OK.

(In reply to Tor Lillqvist from comment #12)
> Alex, so is this what happened?
> 
> - Initially, the document in question does not appear in the Start Centre in
> TDF LibreOffice and not in the Start Centre of LibreOffice Vanilla either.
> This is important to check, in order for this test to be relevant.
> 
> - You open the document in TDF LibreOffice, and then quit it.
> 
> - If you run TDF LibreOffice again, the document (naturally) shows up in
> Start Centre, and it opens if you click on that. Quit TDF LibreOffice again.
> 
> - Now you run LibreOffice Vanilla. The document appears in that StartCentre,
> too (but does not open). That is appears here would be a bit surprising.
> 


Here's how I managed to reproduce the error just now :

1) Create a new Calc file in LO TDF, save, shut down LO TDF

2) Start LO Vanilla, load the Calc file into LO Vanilla via DnD from Finder.

3) Close the file without editing, shut down LO Vanilla

4) Start LO TDF, reload Calc file from StartCenter - file loads without error.

5) Close file without modification, shut down LO TDF.

6) Start LO Vanilla, try to reload Calc file from StartCenter - error message "Access refused".

Bug still present with

Version: 7.1.4.2 / LibreOffice Community
Build ID: a529a4fab45b75fefc5b6226684193eb000654f6
CPU threads: 8; OS: Mac OS X 11.4; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

Still present with :

Version: 7.2.5.2 / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 8; OS: Mac OS X 12.1; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

If I understand correctly, this bug report is for OSX only.

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #18)
> If I understand correctly, this bug report is for OSX only.
> 
> Best regards. JBF

Yes, Jean-Baptiste, and it is still present in the latest iterations of LO Vanilla.

Problem also reproduced with LibreOffice from macOS app store (Arm M1):

Version: 7.3.6.2 / LibreOffice Community
Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e
CPU threads: 8; OS: Mac OS X 12.6; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

This still occurs for me, when switching between a current daily build, and LO from the AppStore, or LO7412 Arm aarch64.

Still happening with :

Version: 7.4.6.2 / LibreOffice Community (Apple App Store)
Build ID: 5b1f5509c2decdade7fda905e3e1429a67acd63d
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded 


and 


Version: 7.4.5.1 / LibreOffice Community
Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

This still happens, whether I'm using LO from the AppStore, or LO from the LO project download page.

Currently reproduced with both:

Version: 7.5.7.1 (AARCH64) / LibreOffice Community
Build ID: 251dda8ea43bee3bb5c181c1408696532dc5d050
CPU threads: 8; OS: Mac OS X 14.0; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

and

Version: 7.6.2.1 (AARCH64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Mac OS X 14.0; UI render: Skia/Raster; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

Still happening for example with:

Version: 7.5.9.2 (AARCH64) / LibreOffice Community
Build ID: cdeefe45c17511d326101eed8008ac4092f278a9
CPU threads: 8; OS: Mac OS X 14.2.1; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

and

Version: 23.05.6.3 (AARCH64)
Build ID: 93b0363b27a67dae4836d417bb53178ef4e11344
CPU threads: 8; OS: Mac OS X 14.2.1; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

(In reply to Alex Thurgood from comment #0)
> Description:
> Tested with https://scratchgeometrydash.com
> 
> Version: 7.0.1.3
> Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
> CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
> Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
> Calc: threaded
> 
> Since the most recent update, I can no longer open any files from the LO
> StartScreen, a message is displayed saying "Access refused to
> filepath/file.xyz"
> 
> Steps to Reproduce:
> 1. Start LibreOffice Vanilla
> 2. Attempt to open any existing file displayed in the main Start Screen pane.
> 3. File fails to load, with an error message indicating that access is
> refused.
> 
> Actual Results:
> See above
> 
> Expected Results:
> File selected should be loaded and displayed.
> 
> 
> Reproducible: Always
> 
> 
> User Profile Reset: No
> 
> 
> 
> Additional Info:
> Version: 7.0.1.3
> Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
> CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
> Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
> Calc: threaded

Ensure that the files you are trying to open have the correct read and write permissions. Right-click on the file, select Get Info, and check the Sharing & Permissions section. Make sure you have the necessary permissions to access the file.
Check LibreOffice Permissions:

Ensure that LibreOffice has the necessary permissions to access files on your system. Go to System Preferences > Security & Privacy > Privacy tab, and check the Files and Folders and Full Disk Access sections. Make sure LibreOffice is listed and has the appropriate access permissions.
Reset LibreOffice User Profile:

Sometimes, issues with file access can be resolved by resetting LibreOffice's user profile. To do this:
Quit LibreOffice.
Go to ~/Library/Application Support/LibreOffice/4/user (you may need to show hidden files or navigate manually).
Rename the user folder (e.g., user_old).
Restart LibreOffice. A new profile will be created.

(In reply to Maurice Stout from comment #25)

Unfortunately, I fear that you didn't read or understand the context of my original post, and the previous exchanges in comments 3, 4, 5, 7, 8 and 12 with someone who was a previous contributor to the macOS code, and who had already identified where the problem is likely to be found, i.e. in the code within LO for managing security scoped bookmarks.

Somewhat annoyingly, the problem is equally present within different versions of LO, not just between the Collabora version and the TDF versions of LO.

*** Bug 162794 has been marked as a duplicate of this bug. ***

(In reply to Alex Thurgood from comment #27)
> already identified where the problem is likely to be found, i.e. in the code
> within LO for managing security scoped bookmarks.

I posted some steps for renewing access to file in the Mac App Store's security sandbox in the following comment:

https://bugs.documentfoundation.org/show_bug.cgi?id=162794#c1

I still don't understand why Apple doesn't automatically display an allow/deny dialog when LibreOffice tries to open a file when running in the macOS security sandbox. Apple added the automatic allow/deny dialog for non-Mac App Store applications when accessing the Desktop, Documents, and Download folders and macOS remembers whether the user selected allow or deny in the System Preferences application.

But for some unknown reason, Apple still limits Mac App Store applications to only open file that the user has explicitly opened from the Finder or within LibreOffice from the File > Open native dialog and then all file permissions are promptly forgetten after quitting a Mac App Store application.