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:
Saving a Calc file is impossible.
Be able to save a Calc file containing the copied data to a place of the user's choosing.
User Profile Reset: Yes
See also bug 126638
*** This bug has been marked as a duplicate of bug 126638 ***
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 :
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.
@Choph, this issue seems to be related to the notarization process
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.
I set to NEW
*** Bug 129133 has been marked as a duplicate of this bug. ***
(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.
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.
The part "with parallel LO installations" could very well be dropped from the summary.
*** Bug 131017 has been marked as a duplicate of this bug. ***
*** Bug 130883 has been marked as a duplicate of this bug. ***
*** Bug 131666 has been marked as a duplicate of this bug. ***
*** Bug 128690 has been marked as a duplicate of this bug. ***
*** Bug 130209 has been marked as a duplicate of this bug. ***
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
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
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
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
*** Bug 133044 has been marked as a duplicate of this bug. ***
*** Bug 131292 has been marked as a duplicate of this bug. ***
*** Bug 132025 has been marked as a duplicate of this bug. ***
As already suggested in duplicate Bug 132025:
codesign -vvv --deep --strict LibreOffice.app
automatically by the language pack installer would solve the problem?
*** Bug 134547 has been marked as a duplicate of this bug. ***
*** Bug 135353 has been marked as a duplicate of this bug. ***
*** Bug 134848 has been marked as a duplicate of this bug. ***
Env: macOS 10.15.5 catalina.
Just tested with version 188.8.131.52
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 184.108.40.206 where the problem does not exist (at least not on my Mac).
I am very diapointed...
(In reply to Rob from comment #26)
This still works, even with 220.127.116.11 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?
*** Bug 135481 has been marked as a duplicate of this bug. ***
*** Bug 135511 has been marked as a duplicate of this bug. ***
(In reply to cpohle from comment #27)
> This still works, even with 18.104.22.168 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 22.214.171.124;
Totally unclear to me why version 126.96.36.199 does work 'out of the box'.
Anyway, as the solution seems to be known, how much work is involved in implementing this?
*** Bug 135564 has been marked as a duplicate of this bug. ***
Same problem, unable to Save As a new document.
MacOS Catalina 10.15.6
(In reply to Tim from comment #32)
> Same problem, unable to Save As a new document.
> LibreOffice 188.8.131.52
> MacOS Catalina 10.15.6
For me the command described in Comment #c27 solved the problem.
Same problem with
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
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
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.
*** Bug 136759 has been marked as a duplicate of this bug. ***