When an opened document on a network drive will be closed the semaphore file (.~lock.xxx.odt# etc.) is not deleted. I have reproduced the beavior with LO 26.2.0 beta and LO 26.8.0.0 alpha in Writer and in Calc. To reproduce the problem find or create a test document on a network ressource and follow the cases described below. Additionally watch the entries in the folder containing the test document - make show also hidden files! - When the opened document was not changed before close the not deleted semaphore file causes the document can be opened on other computers only readonly. On the same computer (and by the same user?) it can be opened without any problems. - When the document was changed LO asks for save before close. Even if the user decides to save the document or not the file attribute "readonly" is set. The next time the document can be opened only readonly. In case the user decides to "Save as" not the original file but the saved as document gets the file attribute readonly. When one tries to solve the problem by manually delete the semaphore file and clear the readonly attribute there are other problems. The document can be opened without any problems but when one tries to save the document (with or without any changes) one gets error messages as "Fehler beim Speichern des Dokuments xxx: / Kein Zugriff auf Objekt. / Aufgrund fehlender Zugriffsrechte kann auf das Objekt nicht zugegriffen werden." (ger, en [lt. Google]: "Error saving document xxx: / No access to object. / Due to insufficient access rights, the object cannot be accessed.") - test with LO 26.8.0.0 alpha - or with LO 26.2 Beta also "Fehler beim Speichern des Dokuments xxx: Fehler beim Erstellen des Objekts. / Sicherungskopie konnte nicht erstellt werden." (ger, en: "Error saving document xxx: Error creating object. / Backup could not be created.") This behavior is already described in Bug 160484.
Addition: I cannot reproduce the problem with LO 25.8.4.
Would now be nice to get a bibisect of the bug - https://wiki.documentfoundation.org/QA/HowToBibisect Please could you do it?
I have bisected the bug and here is the result: ec31a2b8d8077a1c7a9efcc3d1cd4626a643dba4 is the first bad commit commit ec31a2b8d8077a1c7a9efcc3d1cd4626a643dba4 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Oct 11 08:39:15 2025 -0700 source 1a4f72f03b1bd49d486e52135e78971242fae649 source 1a4f72f03b1bd49d486e52135e78971242fae649 instdir/program/sal3.dll | Bin 680448 -> 680448 bytes instdir/program/setup.ini | 2 +- instdir/program/version.ini | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-)
Based on the logs to the source ID 1a4f72f03b1bd49d486e52135e78971242fae649 given by bisect and to the Build IDs d60ff8c8bd4e3ebf8f84f53448ead3c838332ea9 (LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64 from 2025-10-11_03.29.22, last Windows build with behavior OK: semaphore file was deleted) 09e5cf69b30afe46c037aca024b6014d012b0081 (LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64 from 2025-10-13_03.28.43, first Windows build with the bug: semaphore file was kept at close) I think the list of changes "candidate" for causing the bug can be limited to the following: 1a4f72f tdf#150118: fix call to AccessCheck by Mike Kaganski · 3 months ago 93e3ed3 ofz Use-of-uninitialized-value by Caolán McNamara · 3 months ago 5215448 ofz Use-of-uninitialized-value by Caolán McNamara · 3 months ago 293a41d ofz#446998346 Direct-leak by Caolán McNamara · 3 months ago 9eb3f5d tdf#151144 add opencl controls to calc > calculate tab page by Sahil Gautam · 3 months ago ceb2254 tdf#151144 replace threading/opencl labels with a generic calculation label by Sahil Gautam · 3 months ago 6af1836 tdf#151144 remove opencl tab page by Sahil Gautam · 3 months ago b36f181 tdf#168777: Trailing space must show all decorations, also for ODF by Mike Kaganski · 3 months ago 3e9a613 Update git submodules by Alain Romedenne · 3 months ago
Correction to Comment 4: The Ids of the both Windows builds are reversed, sorry! correct: 09e5cf69b30afe46c037aca024b6014d012b0081 = LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64 from 2025-10-11_03.29.22, last Windows build with behavior OK: semaphore file was deleted d60ff8c8bd4e3ebf8f84f53448ead3c838332ea9 = LibreOfficeDev_26.2.0.0.alpha0_Win_x86-64 from 2025-10-13_03.28.43, first Windows build with the bug: semaphore file was kept at close The resulting canditates list is OK.
(In reply to Stefan_Lange_KA@T-Online.de from comment #3) > I have bisected the bug and here is the result: > ec31a2b8d8077a1c7a9efcc3d1cd4626a643dba4 is the first bad commit > commit ec31a2b8d8077a1c7a9efcc3d1cd4626a643dba4 > Author: Norbert Thiebaud <nthiebaud@gmail.com> > Date: Sat Oct 11 08:39:15 2025 -0700 > > source 1a4f72f03b1bd49d486e52135e78971242fae649 > > source 1a4f72f03b1bd49d486e52135e78971242fae649 > > instdir/program/sal3.dll | Bin 680448 -> 680448 bytes > instdir/program/setup.ini | 2 +- > instdir/program/version.ini | 2 +- > 3 files changed, 2 insertions(+), 2 deletions(-) Thank you for bisect. Adding Cc: to Mike Kaganski ; Could you possibly take a look at this one? Thanks
(In reply to raal from comment #6) > Adding Cc: to Mike Kaganski ; Could you possibly take a look at this one? No. The identified commit only made a final change to enable commit 1b5d039d8b5861b5ea21ef00ff521c6e2565105f. When reviewing it, I made a suggestion to avoid passing PrivilegeSet to the call of AccessCheck. Balazs followed my advise, which turned out wrong. And then I simply make the change that Balazs intended to implement originally. If the abovementioned change (implemented properly) causes that unwanted consequence in not a problem of my change.
The commit 1b5d039d8b5861b5ea21ef00ff521c6e2565105f is from 2025-10-10 14:24:40 UTC and it was already in the build 09e5cf69b30afe46c037aca024b6014d012b0081. But when I understand right the answer of Mike Kaganski in Comment 7 it was still not active (enabed only by his change 1a4f72f03b1bd49d486e52135e78971242fae649 from 2025-10-11 15:28:03 UTC). OK? This could explain because the bug still didn't occur in the build 1b5d039d8b5861b5ea21ef00ff521c6e2565105f but first in d60ff8c8bd4e3ebf8f84f53448ead3c838332ea9. Could it make sense to investigate commit (change) 1b5d039d8b5861b5ea21ef00ff521c6e2565105f? The subject of this change (access check , readonly attribute, ...) does not, at least, rule out a connection to the bug.
Sorry, a wrong build Id again! Correction to Comment 8: This could explain because the bug still didn't occur in the build 09e5cf69b30afe46c037aca024b6014d012b0081 but first in d60ff8c8bd4e3ebf8f84f53448ead3c838332ea9.
(In reply to Stefan_Lange_KA@T-Online.de from comment #8) > But when I understand right the answer of Mike Kaganski in Comment 7 it was > still not active (enabed only by his change > 1a4f72f03b1bd49d486e52135e78971242fae649 from 2025-10-11 15:28:03 UTC). OK? Yes. Balazs: is implementing commit 1b5d039d8b5861b5ea21ef00ff521c6e2565105f, and his WIP passes a temporary PrivilegeSet to AccessCheck. Adds Mike as a reviewer. Mike: reads it, checks the documentation of AccessCheck, sees that PrivilegeSet is documented optional, and suggest to avoid that instead. Balazs: follows Mike's advise, and merges commit 1b5d039d8b5861b5ea21ef00ff521c6e2565105f. Mike: sees the commit has been merged, pulls fresh master, builds, and tests - and sees that the intended functionality is not working at all. He debugs it, and sees that the call to AccessCheck fails; he tests that the failure is causes by not passing PrivilegeSet to it; then he creates and merges follow up commit 1a4f72f03b1bd49d486e52135e78971242fae649, which result is simply "Balazs' original change".
*** Bug 170615 has been marked as a duplicate of this bug. ***
Let's open it an increase importance
*** Bug 170794 has been marked as a duplicate of this bug. ***
*** Bug 170704 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/51f7a76441e6d80c4457ef2e0492999a27a3d74b tdf#170297: Revert "tdf#150118: fix call to AccessCheck" (26.2 only) It will be available in 26.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/753caf32360c25866b2c1cbe8c5f4d8c8733128f tdf#170297: Revert "tdf#150118 check file permissions on windows if have no readonly" (26.2 only) It will be available in 26.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-26-2-1": https://git.libreoffice.org/core/commit/a043a8b4eda3ae8145f7342cd9d1336ae01594a8 tdf#170297: Revert "tdf#150118: fix call to AccessCheck" (26.2 only) It will be available in 26.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-26-2-1": https://git.libreoffice.org/core/commit/a3dad8129ffc20df67e2b5ca47366f21ab996375 tdf#170297: Revert "tdf#150118 check file permissions on windows if have no readonly" (26.2 only) It will be available in 26.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The patches causing this issue have been reverted in libreoffice-26-2 and libreoffice-26-2-1 branches. The issue is still reproducible in master. Updating data accordingly
*** Bug 170912 has been marked as a duplicate of this bug. ***
(In reply to Commit Notification from comment #18) > Xisco Fauli committed a patch related to this issue. > It has been pushed to "libreoffice-26-2-1": > > https://git.libreoffice.org/core/commit/ > a3dad8129ffc20df67e2b5ca47366f21ab996375 > > tdf#170297: Revert "tdf#150118 check file permissions on windows if have no > readonly" (26.2 only) > > It will be available in 26.2.1. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. I think there is a problem: After LO 26.2.0 beta was published I cannot find any new development builds for LO 26.2 because in the folder "Daily" there is no subfolder for 26.2. Or do I need better glasses? ☹
I think it is OK! When I looked the last time in the master folder (this morning!) there was still LO 26.8. alpha but now it is replaced by LO 26.2.
*** Bug 170914 has been marked as a duplicate of this bug. ***
Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/75d572302767eac4596d56b0ac848b39825b8013 tdf#170297: skip AccessCheck for remote drives in osl_getFileStatus It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #24) > Balazs Varga committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 75d572302767eac4596d56b0ac848b39825b8013 > > tdf#170297: skip AccessCheck for remote drives in osl_getFileStatus > > It will be available in 26.8.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. One small question: when will 26.8.0 be available publicly? Thx
Perfect! I have tested in Writer ans Calc with newest LO 26.8.0 downloaded from /daily/master/Win-x86_64@tb103-1-TDF/2026-02-23_21.20.22/: Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 680(Build:0) CPU threads: 4; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded Result: At open of a remote document the semaphore file was created and on close it was deleted (disappeared). The file attributes were not changed (no ReadOnly was set). For me seems the problem is solved. I hope the patch will be pushed also to LO 26.2.2 - and maybe also DevBuilds for 26.2 will be available again. Answer to the question for release date of LO 26.8.0 [Karo]: Still there is no release plan for 26.8 but as the name "26.8" says it will be probably in August 2026 - at least so it was since LO 24.2.
(In reply to Stefan_Lange_KA@T-Online.de from comment #26) > Perfect! > I have tested in Writer ans Calc with newest LO 26.8.0 downloaded from > /daily/master/Win-x86_64@tb103-1-TDF/2026-02-23_21.20.22/: > > Version: 26.8.0.0.alpha0+ (X86_64) > Build ID: 680(Build:0) > CPU threads: 4; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; > VCL: win > Locale: de-DE (de_DE); UI: de-DE > Calc: CL threaded > > Result: At open of a remote document the semaphore file was created and on > close it was deleted (disappeared). The file attributes were not changed (no > ReadOnly was set). For me seems the problem is solved. Thanks for testing it! > > I hope the patch will be pushed also to LO 26.2.2 - and maybe also DevBuilds > for 26.2 will be available again. No need for that. the problematic commits were reverted in that branch. > > Answer to the question for release date of LO 26.8.0 [Karo]: Still there is > no release plan for 26.8 but as the name "26.8" says it will be probably in > August 2026 - at least so it was since LO 24.2. Yes, that's correct. It will be released in August 2026
After the test yesterday night with LO 26.8.0 alpha I have tested today also with Version: 26.2.1.2 (X86_64) Build ID: 620(Build:2) CPU threads: 4; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded (yesterday published as pre-release) Result: Also OK!
Thank you so much to all the people who worked on this problem. If I am interpreting the comments in this thread correctly, it appears that the problem has been resolved. Is that correct? If so, it appears that in order to apply the resolution, something needs to be done on the end-user's side. Since I am a newbie to Bugzilla and LibreOffice, I am not sure how to apply the fix on my computers. Would anyone be able to instruct me on this and whether or not there are any caveats to applying the resolution? Thank you again for all your help! I will also be making a donation to LibreOffice. Wayne
*** Bug 171007 has been marked as a duplicate of this bug. ***
(In reply to Wayne Kolb from comment #29) > Thank you so much to all the people who worked on this problem. If I am > interpreting the comments in this thread correctly, it appears that the > problem has been resolved. Is that correct? > > If so, it appears that in order to apply the resolution, something needs to > be done on the end-user's side. Since I am a newbie to Bugzilla and > LibreOffice, I am not sure how to apply the fix on my computers. > > Would anyone be able to instruct me on this and whether or not there are any > caveats to applying the resolution? > > Thank you again for all your help! > > I will also be making a donation to LibreOffice. > > Wayne Resolved: It is correct! From the released LibreOffice versions only LO 26.2.0 is affected by the bug but not all versions of LO 25.8! If LO 26.2.0 is installed on your computers you can ... ... go back to e.g. to LO 25.8.5 (recently released): --> uninstall LO 26.2.0 (program + help) and install LO 25.8.5 by downloaded installation files (see below) ... or better wait until LO 26.2.1 will be released (planned: Week 9 , Feb 23, 2026 - Mar 1, 2026): --> download LO 26.2.1 installation files (see below) and simply install LO 26.2.1 (installed version LO 26.2.0 will by replaced/overwritten) Download installation files: visit https://www.libreoffice.org/download/download-libreoffice/ and download the the desired installation files (program + help pack in your language) for LO 25.8.5 or LO 26.2.1 (when available) If you are familiar with installation and uninstallation of programs I think there will be no problems. Stefan
Thank you, Stefan. You're instructions are very clear. I used to work IT support so I should be good on the uninstall and re-install. Based on what you suggested, I will probably wait until LO 26.2.1 comes out. In the meantime, at least my household is aware of it, and we can simply turn off the read-only state of the file just after saving or just prior to opening a document. I will let you know how it goes after I install the new version of LO. Again, Thank you for all your help! Wayne
*** Bug 171008 has been marked as a duplicate of this bug. ***
(In reply to Wayne Kolb from comment #32) > Based on what you suggested, I will probably wait until LO 26.2.1 comes out. > In the meantime, at least my household is aware of it, and we can simply > turn off the read-only state of the file just after saving or just prior to > opening a document. You can already install a 26.2.1.2 pre-release from: https://dev-builds.libreoffice.org/pre-releases/win/x86_64/ Installed it this afternoon and saving on the network works fine again.
Excellent! Great to know. I will try the pre-release as soon as I can and let you know how it worked for me.
All, I am happy to report that after installing the LO 26.2.1.2 pre-release, I am now able to save documents without having the Read-only file property automatically being set on those documents! Thank you to everyone who worked on this for all your help! It is greatly appreciated. Wayne
*** Bug 170917 has been marked as a duplicate of this bug. ***
*** Bug 171033 has been marked as a duplicate of this bug. ***
*** Bug 160315 has been marked as a duplicate of this bug. ***
Created attachment 206131 [details] Bug summary (ODS sharing was also affected by this regression) In addition to the read-only attribute being set on files saved to SMB shares (the primary symptom of tdf#170297), the regression also broke spreadsheet collaboration. When a spreadsheet was shared for collaboration (Tools → Share Spreadsheet) using a properly working Calc version (e.g. 24.2, 25.2, 25.8), and then opened in the regressed 26.2.0.3, Calc created a .~lock. file alongside the existing .~sharing. file. Because the .~lock. file received the Read-Only attribute on the SMB share and was not removed on close, subsequent attempts to open the shared spreadsheet were blocked — effectively making collaboration impossible. The issue is resolved in 26.2.1.2 (where the problematic commits were reverted in: 51f7a76441e6d80c4457ef2e0492999a27a3d74b and 753caf32360c25866b2c1cbe8c5f4d8c8733128f).
*** Bug 170847 has been marked as a duplicate of this bug. ***
(In reply to Piotr Osada from comment #40) > Created attachment 206131 [details] > Bug summary (ODS sharing was also affected by this regression) > > In addition to the read-only attribute being set on files saved to SMB > shares (the primary symptom of tdf#170297), the regression also broke > spreadsheet collaboration. When a spreadsheet was shared for collaboration > (Tools → Share Spreadsheet) using a properly working Calc version (e.g. > 24.2, 25.2, 25.8), and then opened in the regressed 26.2.0.3, Calc created a > .~lock. file alongside the existing .~sharing. file. Because the .~lock. > file received the Read-Only attribute on the SMB share and was not removed > on close, subsequent attempts to open the shared spreadsheet were blocked — > effectively making collaboration impossible. > The issue is resolved in 26.2.1.2 (where the problematic commits were > reverted in: 51f7a76441e6d80c4457ef2e0492999a27a3d74b and > 753caf32360c25866b2c1cbe8c5f4d8c8733128f). Is this behavior also resolved in LO 26.8.0 alpha0? The problematic commit was not reverted there and was repaired by a new fix, see Comment 24 Commit Notification 2026-02-23 16:24:14 UTC!
*** Bug 171319 has been marked as a duplicate of this bug. ***