Cannot save using drop-down menu on Catalina

English
, , , ,
#1

Hi

Details: LO 7.0.4.2 on OSX Catalina 15.7 with the latest JRE installed
I have given LO full disk access under Catalina and have tried to save using the LO menus, or via Finder.

I have a lot of files in different locations, I need to keep them there for reasons of version control. I want to be able to open a file from location X and save it back there, not somewhere from where I have to move it.

LO will allow me to save in the path set in Preferences. It will not allow saving in any other location. When I try, the spinning beachball appears and I need to cancel/quit.

This used to work. But it stopped. So I have updated all the above and also reset FDA and rebooted - nothing. I have occasionally had the ‘insufficient user rights’ message but have no idea why - it doesn’t appear consistently when I am trying to save.

Can’t think of anything else to try!

#2

Can’t think of anything else to try!

Two things ti try (assuming reset FDA means "I have completely removed LibreOffice.app from list of applications havikng Full Disk Access and added LibreOffice.app to the list again)

#3

Thanks for this - I restarted LO and tried to save after each. Neither have worked :frowning:

I notice under the JRE there is provision for logging - should I try this? Or would I look for log entries under Python?

Best

R

#4

JRE / (JDK in case of macOS) is not involved in that and no idea what Python should have got to do with a problem saving to certain directirories. My gut feeling rather directs me to check the ownership and permissions of files and directories within your home directory using a terminal and command ls -l

#5

Another question - should LO allow me to create (first save) a file in location X and thereafter save the file with the same file name in location Y? Or do I have to use a new file name in order to save in a new location?

If the answer is that a file is irrevocably associated with the location in which it was first saved, then I will prbly file an enhancement request. If it should be possible to save in a different location, then the question stands.

Best

R

#6

Apologies - I was all wrapped up in digging and didn’t see your post. Understand your point.

ls -l shows:

~ ls -l

Documents drwx------@ 29 richardhornby staff

[PATH-TO-DOCUMENT-AS-SAVED-IN-DOCUMENTS-AND-WHICH-CONTINUES-TO-SAVE-IN -DOCUMENTS] ls -l

-rw-r–r–@ 1 richardhornby staff

[PATH-TO-ORIGINAL-DOCUMENT] ls-l

-rwxr-xr-x+ 1 richardhornby staff

Tks

R

#7

DK how to ensure EOL in these posts. Apologies.

R

#8

No - there is absolutely no such thing like a “file to storage location association”. You are absolutely free to store your files under the same name and/or another name, wherever you have permissions to store files to (this is on macOS: /Users/<your_user_name_on_macOS>/ - within that directory you should be absolutely free where to save files to wherever you want; if that doesn’t work there is an issue - and in general: This issue is not a LibreOffice issue (real bugs aside).

#9

I think that’s correct, with one caveat. Staff have read-only permission. A LO question is why this document was created with only that permission. I would have thought that all docs would be created as rw by their creator.

?

Tks

R

#10

DK how to ensure EOL in these posts. Apologies.

** Check my answer below and if the answer works for you, click the check mark (:heavy_check_mark:) next to the answer. Thanks in advance …*

#11

A LO question is why this document was created with only that permission.

No, this is not an LO question - LibreOffice doesn’t set the permission. It is macOS and specifically your umask setting (which by default is 0022 and assures 755 (drwxr-xr-x) on creation of directories and 644 (-rw-r--r--) on creation of files. Execute command umask in a terminal to check whether it is set to 0022. If anything else later changes the permissions then file or directory access is according to new settings; umask determines initial settings. If you want staff to have write permissions, you need to change umask to 0002 and chmod g+w <file> or chmod g+w <dir> on existing files/directories.

#12

And be that as it may, cascading rw permissions to staff throughout the file system where the file was created as well as where I want to save it has solved the problem.

I hesitate to mark as solved by extending rw permission on the destination folder to ‘staff’ because I still don’t know why the file was assigned to ‘staff’ in the first place.

Any thoughts (and tks, I am running now)?

Best

R

#13

Sorry again we are running in parallel.

umask is set to 022.

I don’t know why the file was created with ‘staff’ in the first place. It seems from what you say above that umask is correctly set but for some reason the file is ‘staff’ so permissions need to be -rw-rw-r-- .

I don’t need to restrict who can write to this file as it’s only networked to my other kit. But there may be a question for other users.

Tks

R

#14

the file was assigned to ‘staff’ in the first place.

Sorry - I can’t see any file assigned to staff. All I see is

-rwxr-xr-x+ 1 richardhornby staff <a_file_name_not_visible_in_output>

And this means:

  • <a_file_name_not_visible_in_output> is owned by user richardhornby having read/write/execute permisssions (rwx) and which matches umask 0022 setting
  • <a_file_name_not_visible_in_output> is associated to group staff and all members of group staff have read/execute permisssions (r-x) and which does not match umask 0022 setting
    <a_file_name_not_visible_in_output> has read/execute permisssions (r-x) for all other user of you system and which does not match umask 0022 setting.

So something must be changed in your umask setting since x (execute permission) bit does not make sense in ordinary, non-executable files - remove the x-bit on ODF files (chmod 644 <ODF File>) -


But we have left the LibreOffice scope already ...
#15

And be that as it may, cascading rw permissions to staff throughout the file system where the file was created as well as where I want to save it has solved the problem.

If that solved your problem, the only conclusion is: You are not logged in as user richardhornby

#16

For the records

Check ownership and permissions within you home directory using ls -l in a terminal. It they don’tc provide write access (w flag missing) or no access to directories (x flag missing) provide that using:

chmod u+x <dir> (access to directories for the user)
chmod u+w <dir> (write into specified directory for the user)
chmod u+w <file> (overwrite specified file by user)

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.