steps to reproduce: 1. have a document (odt, docx, etc) on a samba smb3 share (oplocks enabled or disabled did not make a diffrence). 2. open the document with libreoffice 6.4.7-0ubuntu0.20.04.1~lo1 as userA 3. open the document with libreoffice as userB 4.. warning shows up that document is opened by userA, choose to read-only or create a copy... 5. either choosing read-onluy or create-copy will produce an access denied error or empty document. 6. trying to copy the file as userB while opened as userB will also create errors with the caja file-manger under Linux Mint 20. My guess is that libreoffice creates some kind of kernel file lock that also disables the read access instead of only taking away the write access. Then in our setup that also include Collabra (paid support), when Collabora has an document opened, then opening the document with LibreOffice from the samba share does not create any errors or warnings that the document is in use, causing all kind or unwanted situations. However Collabra does throw an error that it can not read the document when the document was first opened with LibreOffice. Any help is appreciated, would like my customers and organizations to be able to use LibreOffice on shared samba drives without the risk of data loss (happened a few times with end-users that did not understand fully what was going on)
Created attachment 169862 [details] dialog with open-copy or read-only
Created attachment 169863 [details] read-only error diaglog
Created attachment 169864 [details] open-copy empty page results
Created attachment 169865 [details] collabora error when opening document inuse by libreoffice
Very similar situation with: Version: 7.3.1.3 / LibreOffice Community Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951 CPU threads: 8; OS: Mac OS X 12.4; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded Google Drive creates a Samba share now on macOS which a user can mount. If a file, e.g. Calc document, is opened on that share, then a user with access to the same Google Drive can not open the same file for editing and is informed that the file is opened and locked. As reported by OP, the user is given a choice of opening the file read-only. Choosing this option on macOS fails to produce any noticeable result - no file is opened, no error message is displayed.
(In reply to Alex Thurgood from comment #5) > > As reported by OP, the user is given a choice of opening the file read-only. > Choosing this option on macOS fails to produce any noticeable result - no > file is opened, no error message is displayed. Actually, it does eventually open, after about 10 minutes ! This is quite a significant regression over previous behaviour, as the read-only copy used to open more or less instantaneously. Unfortunately, this may be down to Google's implementation of its drive mount on macOS.
I could not reproduce with LO 6.4.7.2 nor a recent master build, using a share between Ubuntu 20.04 and Windows 10. Jelle, can you please: - test again with a currently supported version, 7.4 or 7.5 - if you can still reproduce, paste here the version info copied from Help > About LibreOffice Regarding the Collabora side of things, please do go through paid support if you are still able to. Thank you!
I ran trough all the steps and they are still fully reproducible for me. Where both users working from the SMB3 share when trying to reproduce. We are using SAMBA. Version: 7.4.6.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: nl-NL (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.4.6-0ubuntu0.20.04.1~lo1 Calc: threaded
Created attachment 185889 [details] dialog with open-copy or read-only
Created attachment 185890 [details] read-only error diaglog
Created attachment 185891 [details] caja file-manger under Linux Mint error
Created attachment 185892 [details] collabora error when opening document inuse by libreoffice
Created attachment 185893 [details] libreoffice 7.4 about info
[Automated Action] NeedInfo-To-Unconfirmed
Dear Jelle de Jong, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug