Bug 128233 - macOS: Can't save or open files using Finder dialog on Standard accounts on macOS 10.15 Catalina
Summary: macOS: Can't save or open files using Finder dialog on Standard accounts on m...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.2.2 release
Hardware: x86-64 (AMD64) macOS (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 128690 129133 130209 130883 131017 131292 131666 132025 133044 134547 134848 135353 135481 135511 135564 136759 136981 139410 139679 143681 144964 (view as bug list)
Depends on: 126409
Blocks: MacOS-Wishlist Desktop-Integration Save
  Show dependency treegraph
 
Reported: 2019-10-18 14:09 UTC by Alex Thurgood
Modified: 2021-10-25 12:00 UTC (History)
35 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2019-10-18 14:09:38 UTC
Description:
1) Create new Calc sheet as a non-administrator user of a macOS 10.15 system.
2) Enter some data.
3) Try to "Save As". The operation refuses to work. No Finder dialog is displayed.
4) The document title remains as Sans Nom 1 (Untitled 1) and can not be saved anywhere.
5) The beachball of death rotates for a while, then returns focus to the application.


For what it is worth, the ODS file contains column headers and data from a copy/paste operation from a database table.

Steps to Reproduce:
See above

Actual Results:
Saving a Calc file is impossible.

Expected Results:
Be able to save a Calc file containing the copied data to a place of the user's choosing.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Comment 1 Alex Thurgood 2019-10-18 14:10:51 UTC
See also bug 126638
Comment 2 Alex Thurgood 2019-10-18 14:25:16 UTC

*** This bug has been marked as a duplicate of bug 126638 ***
Comment 3 Xisco Faulí 2019-10-25 08:38:59 UTC Comment hidden (obsolete)
Comment 4 Alex Thurgood 2019-10-29 09:32:44 UTC
Uncoupling this from bug 126638 as I believe I have found the cause of the behaviour I reported and it appears to be different to what the OP is reporting in that bug.

I have found that the problem in my case reported here in this bug report arises when there are parallel installations of LibreOffice, with names other than just "LibreOffice".

It appears that the notarization process must lock in the name of the app bundle somewhere in the system, and if that name is changed, for example, when a user installs an "evolution" version of LO in parallel to a "stable" version, then calling any Finder dialog is blocked by the OS.

I tried this with several different functions from within LO that are supposed to call a Finder dialog :

Save as
Export
Adding a JAR archive under Preferences (for database driver configuration)

Each time, I get a beachball and no Finder dialog, effectively blocking the operation.

If I delete one of my parallel LO installations and rename the surviving one back to LibreOffice, everything seems to work as normal again.

Editing title to better reflect findings.
Comment 5 Xisco Faulí 2019-11-07 14:57:50 UTC
@Choph, this issue seems to be related to the notarization process
Comment 6 Alex Thurgood 2019-11-21 10:02:03 UTC
No doubt adding the application bundle to the list of "Full Disk Access" apps might solve this.

The installation should take of this, though, and it doesn't. Asking a user to specifically manually bypass the security model to allow whole disk access is bit of a problem.
Comment 7 Ahmad Haris 2019-11-26 13:28:31 UTC
I set to NEW
Comment 8 Alex Thurgood 2019-12-02 08:42:51 UTC
*** Bug 129133 has been marked as a duplicate of this bug. ***
Comment 9 Paul Oranje 2019-12-03 22:57:15 UTC
(In reply to Alex Thurgood from comment #6)
> No doubt adding the application bundle to the list of "Full Disk Access"
> apps might solve this.
> 
> The installation should take of this, though, and it doesn't. Asking a user
> to specifically manually bypass the security model to allow whole disk
> access is bit of a problem.

On Catalina:

When LO is installed (in my case with Homebrew) "Save" and "Save as" dialogs run fine, but once the LO app is **changed** by running a language pack (installer), these (Finder) dialogs cannot be invoked any more.

By adding the (changed) LO app to the list of apps that are allowed "Full Disk Access", then the save dialogs can be invoked again.

In short: your suggestion is correct and relevant for the installation of language packs, because that installation should also refresh any relevant permission for the (changed) LO app.
Comment 10 Paul Oranje 2019-12-03 23:16:42 UTC
The part "with parallel LO installations" could very well be dropped from the summary.
Comment 11 Alex Thurgood 2020-03-02 08:13:14 UTC
*** Bug 131017 has been marked as a duplicate of this bug. ***
Comment 12 eisa01 2020-04-10 09:46:31 UTC
*** Bug 130883 has been marked as a duplicate of this bug. ***
Comment 13 eisa01 2020-04-10 09:47:32 UTC
*** Bug 131666 has been marked as a duplicate of this bug. ***
Comment 14 eisa01 2020-04-10 09:48:28 UTC
*** Bug 128690 has been marked as a duplicate of this bug. ***
Comment 15 eisa01 2020-04-10 09:55:38 UTC
*** Bug 130209 has been marked as a duplicate of this bug. ***
Comment 16 eisa01 2020-04-10 14:56:58 UTC
So I installed Catalina on a fresh drive to investigate this issue.

As far as I can tell, this may be related to the code signing that is broken.

Granting "Full Disk Access" makes the issue go away
Comment 17 eisa01 2020-04-10 15:12:32 UTC
This may be hard to replicate, as now my copy of LO on a standard account is working without Full Disk Access. It may be because I manually verified using the command line to check the output from bug 126409, I don't know.

It's best done on a completely fresh install on a new Standard user to mimic what a new user would encounter

Version: 6.4.2.2
Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 4; OS: Mac OS X 10.15.4; UI render: default; VCL: osx; 
Locale: en-US (en_NO.UTF-8); UI-Language: en-US
Calc: threaded
Comment 18 Alex Thurgood 2020-05-13 07:59:29 UTC
Reproduced with

Version: 7.0.0.0.alpha1
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 8; OS: Mac OS X 10.15.4; UI render: GL; VCL: osx; 
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded
Comment 19 Alex Thurgood 2020-05-15 07:15:12 UTC
*** Bug 133044 has been marked as a duplicate of this bug. ***
Comment 20 Alex Thurgood 2020-06-02 08:48:49 UTC
*** Bug 131292 has been marked as a duplicate of this bug. ***
Comment 21 steve 2020-07-22 13:53:34 UTC
*** Bug 132025 has been marked as a duplicate of this bug. ***
Comment 22 cpohle 2020-07-22 21:52:49 UTC
As already suggested in duplicate Bug 132025: 

Maybe running

   codesign -vvv --deep --strict LibreOffice.app

automatically by the language pack installer would solve the problem?
Comment 23 Timur 2020-07-23 08:17:44 UTC
*** Bug 134547 has been marked as a duplicate of this bug. ***
Comment 24 Julien Nabet 2020-08-01 07:14:23 UTC
*** Bug 135353 has been marked as a duplicate of this bug. ***
Comment 25 Telesto 2020-08-01 14:45:05 UTC
*** Bug 134848 has been marked as a duplicate of this bug. ***
Comment 26 Rob 2020-08-05 17:48:38 UTC
Env: macOS 10.15.5 catalina.

Just tested with version 7.0.0.3

Situation exactly the same. Still can't "save as", "save a copy".

Don't want to change the security settings on my Mac. 
Going back to LO 6.3.6.2 where the problem does not exist (at least not on my Mac).

I am very diapointed...
Comment 27 cpohle 2020-08-05 21:24:22 UTC
(In reply to Rob from comment #26)

This still works, even with 7.0.0.3 release, and does not imply weakened macOS security settings:

>    codesign -vvv --deep --strict /Applications/LibreOffice.app

Couldn't this just be added to the langpack installer routine?
Comment 28 Telesto 2020-08-06 08:25:56 UTC
*** Bug 135481 has been marked as a duplicate of this bug. ***
Comment 29 Telesto 2020-08-07 04:54:08 UTC
*** Bug 135511 has been marked as a duplicate of this bug. ***
Comment 30 Rob 2020-08-07 12:39:01 UTC
(In reply to cpohle from comment #27)

> This still works, even with 7.0.0.3 release, and does not imply weakened
> macOS security settings:
> 
>   codesign -vvv --deep --strict /Applications/LibreOffice.app
> 
> Couldn't this just be added to the langpack installer routine?

This works for me...

Agree with cpohle that it's odd that this isn't addded to the language installer. The bproblem exists in all versions after 6.3.6.2;
Totally unclear to me why version 6.3.6.2 does work 'out of the box'.

Anyway, as the solution seems to be known, how much work is involved in implementing this?
Comment 31 Julien Nabet 2020-08-09 09:15:19 UTC
*** Bug 135564 has been marked as a duplicate of this bug. ***
Comment 32 Tim 2020-08-10 10:57:04 UTC
Same problem, unable to Save As a new document.

LibreOffice 7.0.0.3
MacOS Catalina 10.15.6
Comment 33 Rob 2020-08-10 14:18:01 UTC
(In reply to Tim from comment #32)
> Same problem, unable to Save As a new document.
> 
> LibreOffice 7.0.0.3
> MacOS Catalina 10.15.6

For me the command described in Comment #c27 solved the problem.
Comment 34 Gerry 2020-08-20 15:14:31 UTC
Same problem with
Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU-Threads: 4; BS: Mac OS X 10.15.6; UI-Render: Standard; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded 

on macOS Catalina 10.15.6 

Also for me this solved the problem
1. Open console
2. change the directory to the app folder
3. codesign -vvv --deep --strict LibreOffice.app
Comment 35 Peter N. Steinmetz 2020-08-26 21:06:54 UTC
Also having this problem after installing on Mac OS 10.15.6. Providing full disk access fixed the problem. 

There is another problem here in that the beachball just spins and then the focus returns to the app with no explanation. There should at least be a modal dialog explaining what happened. 

Clearly the installation process is not working as seamlessly as it should.
Comment 36 Julien Nabet 2020-09-15 07:14:14 UTC
*** Bug 136759 has been marked as a duplicate of this bug. ***
Comment 37 Rob 2020-10-29 23:11:03 UTC
Had the problem back after updating to LO 7.0.3.1
Solved by re-executing:
codesign -vvv --deep --strict /Applications/LibreOffice.app
Comment 38 Alex Thurgood 2020-12-21 09:40:43 UTC
Definitely comes under "Most Annoying" bugs - oh, wait, we don't have that any more. Every time there's a version change of LO, the whole thing raises its ugly head again.
Comment 39 Alex Thurgood 2021-01-19 11:31:17 UTC
*** Bug 139679 has been marked as a duplicate of this bug. ***
Comment 40 Alex Thurgood 2021-01-19 13:34:52 UTC
*** Bug 139410 has been marked as a duplicate of this bug. ***
Comment 41 Uwe Altmann 2021-02-05 18:03:55 UTC
I had the first occurrence of this  with LO 7.1 / MacOS 10.15.7

called from command line, "File open" immediately after starting the program throws:
uwealtmann@UwesMacBookAir ~ % /Applications/LibreOffice.app/Contents/MacOS/soffice
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
2021-02-05 18:37:10.792 soffice[1586:24735] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-05 18:37:20.957 soffice[1586:24787] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-05 18:37:31.036 soffice[1586:24787] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

"New Document" even crashes into document restore with the same output.

Funny thing is that 7.0.4 does open the Finder's file open dialog as well as a new document, but also throws:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

- but nothing else.
Comment 42 Uwe Altmann 2021-02-08 11:24:18 UTC
Funny thing which should be remarked: Opening of files shown in StartCenter by click on them works as expected.
Comment 43 Uwe Altmann 2021-02-11 10:51:44 UTC
Investigation further (Catalina 10.15.7): 
renaming user folder and doing clean install of LO 6.4.7, adding german langPack, not having Full Disk Access.
Starting from console as user, 
Create New document is OK, save works OK
Opening existing Document works, but throws five times „(pkix_CacheCert_Add: PKIX_PL_HashTable_Add for Certs skipped: entry existed“. Later doing the same these messages do not repeat.
Save this changed Document works.

Doing clean install of  LO 7.0.4, not having Full Disk Access
everything described above works OK

Doing clean install of  LO 7.1.0, not having Full Disk Access
Starting from console as user, 
Create New document is OK, save  throws 
2021-02-11 09:41:31.302 soffice[92346:1589178] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-11 09:41:41.401 soffice[92346:1589522] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-11 09:41:51.538 soffice[92346:1589629] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted

Open and save of a recently opened document from StartCenter works.

"File open" throws
2021-02-11 09:44:05.786 soffice[92346:1590496] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-11 09:44:15.944 soffice[92346:1590488] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-11 09:44:26.033 soffice[92346:1590674] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted

Starting from console as sudo, 
Create New document is OK, save is OK 
Open and save of a recently opened document from StartCenter works.
"File open" Opening existing Document works, save this changed Document works also.

Using LO 7.0.4 as user not having Full Disk Access
After having installed "Language toll" Extension, opening a document still works but throws 
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Comment 44 Uwe Altmann 2021-03-04 16:31:27 UTC
Updated to 11.2 "BigSur" - and 7.1/7.1.1 works like a charm.

But then: Unable even to start older versions
(to test you have to rename "user" -folder in ~/Library/Application Support/LibreOffce/4/ or it quits with some error on java version at start.)
6.2. at start brings up a Dialog window ""LibrOffice can not be opened because Apple cannot look inside the app to search for malicious software" and recommends to update. OK quits the app.
6.3. dies silently; started at command line, it just says "Application Error" and quits.
Comment 45 Brian Dobby 2021-04-07 09:16:06 UTC
I have the same problem using Draw v 7.1.2.2
Comment 46 Julien Nabet 2021-08-03 07:18:07 UTC
*** Bug 143681 has been marked as a duplicate of this bug. ***
Comment 47 Denys Prokhorov 2021-08-09 18:08:20 UTC
(In reply to Alex Thurgood from comment #0)
> Description:
> 1) Create new Calc sheet as a non-administrator user of a macOS 10.15 system.
> 2) Enter some data.
> 3) Try to "Save As". The operation refuses to work. No Finder dialog is
> displayed.
> 4) The document title remains as Sans Nom 1 (Untitled 1) and can not be
> saved anywhere.
> 5) The beachball of death rotates for a while, then returns focus to the
> application.
> 

Repro
Created a new account with standard access rights.
-The document cannot be saved with read-only access.

If you give a standard user access to the LA Read/write application, the bug will disappear.

Additional Info:
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 246f24ebc8227345f13784d9e2f055d813f3d24f
CPU threads: 12; OS: Mac OS X 10.15.7; UI render: default; VCL: osx
Locale: ru-RU (ru_UA.UTF-8); UI: en-US
Calc: threaded

Version: 7.1.5.2 / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
CPU threads: 12; OS: Mac OS X 10.15.7; UI render: default; VCL: osx
Locale: ru-RU (ru_UA.UTF-8); UI: en-US
Calc: threaded
Comment 48 cpohle 2021-08-09 19:26:22 UTC
(In reply to Denys Prokhorov from comment #47)

> Repro
> Created a new account with standard access rights.
> -The document cannot be saved with read-only access.
> 
> If you give a standard user access to the LA Read/write application, the bug
> will disappear.

Would the workaround provided in comment #22 solve the bug for you?
Comment 49 Denys Prokhorov 2021-08-09 20:55:52 UTC

*** This bug has been marked as a duplicate of bug 136981 ***
Comment 50 Denys Prokhorov 2021-08-09 21:09:12 UTC
Sry missclick to duplicate Bug 136981



(In reply to cpohle from comment #48)
> (In reply to Denys Prokhorov from comment #47)
> 
> > Repro
> > Created a new account with standard access rights.
> > -The document cannot be saved with read-only access.
> > 
> > If you give a standard user access to the LA Read/write application, the bug
> > will disappear.
> 
> Would the workaround provided in comment #22 solve the bug for you?

this does not solve the problem
Comment 51 Denys Prokhorov 2021-08-09 21:15:10 UTC
*** Bug 136981 has been marked as a duplicate of this bug. ***
Comment 52 cpohle 2021-08-20 08:00:25 UTC
Still in 7.2.0.4. Would

   sudo codesign -vvv --deep --strict /Applications/LibreOffice.app

really be so difficult to add to the installer routine?
Comment 53 steve 2021-10-08 06:23:22 UTC
*** Bug 144964 has been marked as a duplicate of this bug. ***
Comment 54 Tor Lillqvist 2021-10-20 10:02:05 UTC
> adding German langPack

But adding langpacks is known to by definition break things, as it plonks stuff into the app bundle and thus makes the signature of the app bundle invalid, no? Doing that when investigating this bug only confuses things.
Comment 55 Tor Lillqvist 2021-10-20 10:08:16 UTC
So is this basically a duplicate of the old bug that says that installing langpacks the way it is done (and has always been done), separately into an already installed LibreOffice app bundle, is broken by design?
Comment 56 cpohle 2021-10-20 10:53:14 UTC
Again, not knowing the internals of how the installer works: Would it not be a feasible solution to just run the one-liner from comment 52 at the end of the installation routine to work around this "design issue"?
Comment 57 Uwe Altmann 2021-10-22 07:00:47 UTC
(In reply to Tor Lillqvist from comment #54)
> But adding langpacks is known to by definition break things, as it plonks
> stuff into the app bundle and thus makes the signature of the app bundle
> invalid, no?

The signature gets checked only at first start of the app. We changed this since years so the installer first starts and quits LO in the background (this is why it takes so long to start) and then "plonks stuff" - which worked rather good for a long time.
Comment 58 Tor Lillqvist 2021-10-25 12:00:34 UTC
> The signature gets checked only at first start of the app.

Trusting that sounds like a very ad-hoc hack. Not surprising if it doesn't work any longer. We should have made LO look for translations and other lang pack contents in another place than in the app bundle long ago. (I tried some year ago but it was much harder than expected (like most things in LO are) and I wasn't going to spend weeks on it.)