Problem description: No lock file has been created so the second user is granted with exclusive access as well. Steps to reproduce: 1. A user opens a spreadsheet from linux workstation. The lock file is not created. 2. B user opens the same file form windows workstation. This makes the lock file correctly. 3. A user wants the save the changes. He gets an I/O error message. Note1: The lock file is created fine on local drives. Platform (if different from the browser): Share: samba on linux server (ubuntu or centos 5) User A: CentOS 6, LibreOffice 3.6.2 or 3.4.5 User B: windows xp, LibreOffice 3.6.2, or Mac OS X 10.7.5 LibreOffice 3.6.2 Note2: I have tried with two different servers and LO version and B users system. Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14
I switched to ubuntu 10.04 LTS amd64. It is work correctly. So the problem is centos related. Or gvfs or what I don't care anymore.
Thanks for bugreport It is because LO know nothing about network. Workaround of Gnome: automatically mount samba share to gvfs. It works. Workaround of KDE: copy document from server to temp file, start LO, wait until LO exit, copy document back to server. It not works for lock files. So, problem: LO not works with smb networks at all reproducible in 3.6.3 on FRF 17 KDE
I am facing the same problem on ubuntu 12.04 LTS Workaround of Gnome: automatically mount samba share to gvfs. It works,but it is annoying
*** Bug 65855 has been marked as a duplicate of this bug. ***
I don't understand the Gnoem workaround described in comment #2. In Ubuntu 12.04, I am finding that a cifs mount via /etc/fstab does NOT have this problem. It is only gvfs (via smb:// in nautilus) that doesn't lock the file. This problem also exists for other file types, so I don't know that it is a LibreOffice bug per se. But again, if I could understand the workaround from comment #2 it would help. Thanks
forgot to mention I am using LO 4.1.3 from the LO 4.1 Stable PPA for Ubuntu. But again, unfortunately, I don't think this is a LO bug, rather a samba / cifs / gvfs bug?
(In reply to comment #5) > I don't understand the Gnoem workaround described in comment #2. What described there is not a workaround you can apply. It's what GNOME itself do in order to support apps that don't use GIO. Note that starting with 4.1 you have 'X-GIO-NoFuse=true' in .desktop files, so LO deals itself with network using GIO. > It is only gvfs (via smb:// in nautilus) that doesn't lock the file. With 'X-GIO-NoFuse=true' or without it? > This problem also exists for other file types What do you mean? Other application that usually create locks, don't create lock in that case? > so I don't know that it is a LibreOffice bug per se. I'm not sure. If LO has write permissions to the share, there is no reason why it couldn't create a lock file there.
Maxim: thanks for the help. I did some more testing today. 3-way tests: - 1 Linux client connected to samba share via CIFS connection in fstab - 1 Linux client connected via "smb://" (gvfs) - 1 Windows XP client connected to samba share. I re-setup my samba test share, and now the file locking is working *as expected* in all regards to the "gvfs" connection. The locking is working correctly on the CIFS connection as well, but when the Windows client has a LO file open, and then attempt to open on the CIFS client, instead of the "nice error message" saying it is already opened, would I like to open read only? I instead get a "general input/output error" and the file can't be opened at all. This isn't great, but at least it will not result in multiple users editing the same file. Regarding "other file types", exclude this from the conversation for now. This is not related to LibreOffice and I may not be understanding some samba things correctly. In summary, for Ubuntu gvfs connections (12.04.3) I see *no problems* with LO's file locking methods. For cifs connections, I see a slight annoyance in the error message not displaying correctly, but I believe this to be samba related. Not sure why the gvfs connections weren't locking correctly a few days ago, but from my testing this bug seems *resolved*.
Summary edited for clarity.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
I can still reproduce , ubuntu 15.10 windows share mounted in nautilus. When I create file in Linux, no lock file is created. When I open this file in windows, then lock file is created. When I open file in windows, then I can open file in linux without warning.I can edit file, but when I want to save the file I get message: Error saving the document test: Sharing violation while accessing the object Version: 5.2.0.0.alpha0+ Build ID: d1a49df6833ff16f5cbaf98534eaae62693e520b CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-01-29_02:01:58
same bug, precisely : LibreOffice 5.0.4.2 00m0(Build:2), Ubuntu 15.10 64 bits. I would really like to change the severity to critical ! I add the keyword dataLoss, in the end this is what append in collaborating work. The *same* file (on the same server) accessed by two different ways. The uri returned by gvfs seems the difference. 1) by nautilus share, the lock file is NOT created : gvfs-info /run/user/1001/gvfs/smb-share\:server\=10.17.1.104\,share\=vincent/sansnom2.odt display name: sansnom2.odt edit name: sansnom2.odt name: sansnom2.odt type: regular size: 8132 uri: smb://10.17.1.104/vincent/sansnom2.odt attributes: standard::type: 1 standard::name: sansnom2.odt standard::display-name: sansnom2.odt standard::edit-name: sansnom2.odt standard::icon: application-vnd.oasis.opendocument.text, x-office-document standard::content-type: application/vnd.oasis.opendocument.text standard::size: 8132 standard::allocated-size: 8192 standard::symbolic-icon: application-vnd.oasis.opendocument.text-symbolic, x-office-document-symbolic, application-vnd.oasis.opendocument.text, x-office-document etag::value: 1454524484 id::filesystem: smb-share:server=10.17.1.104,share=vincent time::modified: 1454524484 time::modified-usec: 0 time::access: 1454599439 time::access-usec: 0 time::changed: 1454524484 time::changed-usec: 0 unix::device: 1546747405 unix::inode: 18446744071862013459 dos::is-archive: TRUE 2) by cifs mount, the lock file IS created : mount -t cifs -o user=***,dom=***,uid=*** //10.17.1.104/vincent /home/vincent/yoga2_sauv/ gvfs-info /home/vincent/yoga2_sauv/sansnom2.odt display name: sansnom2.odt edit name: sansnom2.odt name: sansnom2.odt type: regular size: 8132 uri: file:///home/vincent/yoga2_sauv/sansnom2.odt attributes: standard::type: 1 standard::name: sansnom2.odt standard::display-name: sansnom2.odt standard::edit-name: sansnom2.odt standard::copy-name: sansnom2.odt standard::icon: application-vnd.oasis.opendocument.text, x-office-document standard::content-type: application/vnd.oasis.opendocument.text standard::fast-content-type: application/vnd.oasis.opendocument.text standard::size: 8132 standard::allocated-size: 8192 standard::symbolic-icon: application-vnd.oasis.opendocument.text-symbolic, x-office-document-symbolic, application-vnd.oasis.opendocument.text, x-office-document etag::value: 1454524484:0 id::file: l41:206943791 id::filesystem: l41 access::can-read: TRUE access::can-write: TRUE access::can-execute: TRUE access::can-delete: TRUE access::can-trash: TRUE access::can-rename: TRUE time::modified: 1454524484 time::modified-usec: 0 time::access: 1454599439 time::access-usec: 104102 time::changed: 1454599241 time::changed-usec: 577626 unix::device: 41 unix::inode: 206943791 unix::mode: 33279 unix::nlink: 1 unix::uid: 1001 unix::gid: 765460993 unix::rdev: 0 unix::block-size: 16384 unix::blocks: 16 owner::user: vincent owner::user-real: Vincent Lucy owner::group: 765460993
Hello, I can confirm (unfortunately) the same problem with a webdav share (mounted via gvfs in nautilus) and LO 5.1.0.3 (RC3 I believe): The file won't be locked and LOSS-Update problem persists in a collaborative environment. In options->Advanced->Expert configuration all 3 "locking" properties are set to true: UseLocking -> true UseDocumentSystemFileLocking -> true UseDocumentOOoLockFile -> true I would as well tend to see this bug as severe because it inhibits working in a collaborative environment (basically all organizations or companies) with LibreOffice (hence: Linux cannot be used). Tim
Reverting version to the first mentioned in the first comment - Please do not change the version number, it's the first one where the bug is found, Thanks - Sophie
@Sophie: sorry I did change it because at our office we considere it as a regression: the problème doesn't exist with LO 4.2.8.2 (and teams are switching back...) Vincent
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=763521335b01a37c511ae8069cade9b4b69fef66 tdf#56544: Support LO's .~lock.*# file locking over smb, too It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
LO uses a heuristic to decide whether or not to its .~lock.*# file locking, based on the document's URL schema (using it only for the file and sftp schemas). Whether a Samba document is seen by LO with a smb or a file URL depends on how the Samba share is mounted. With the commit from comment 16, the heuristic is changed to also always use that file locking for the smb schema. Backports requested to libreoffice-5-1 towards LO 5.1.2 (<https://gerrit.libreoffice.org/#/c/22295/>), libreoffice-5-1-1 (<https://gerrit.libreoffice.org/#/c/22296/>), and libreoffice-5-0 towards LO 5.0.6 (<https://gerrit.libreoffice.org/#/c/22298/>).
Hello Stephan, so if a smb or webdav(?) share is mounted via the mount command (not via gvfs), LO still uses the .~lock.*# file for locking? If I understand you right, that would not prevent the LOSS-UPDATE problem, because LO would not request a lock from the smb/webdav server (I don't know if that is possible). thanks, Tim
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8896851ddb02d043f3ebcc5b27b907369f0d6730&h=libreoffice-5-1 tdf#56544: Support LO's .~lock.*# file locking over smb, too It will be available in 5.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f93dba17d397c5bf265504e8fbecd6b615e1787&h=libreoffice-5-0 tdf#56544: Support LO's .~lock.*# file locking over smb, too It will be available in 5.0.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-5-1-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=af252f871d398f395542103428c5d4d3d81965cd&h=libreoffice-5-1-1 tdf#56544: Support LO's .~lock.*# file locking over smb, too It will be available in 5.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Tim Banchi from comment #18) > so if a smb or webdav(?) share is mounted via the mount command (not via > gvfs), LO still uses the .~lock.*# file for locking? If an SMB share is mounted into the filesystem, LO will transparently see its content with file URLs. If an SMB share is accessed via GVfs, LO should see its content with smb URLs (but could also see it with FUSE-based file URLs, e.g., when triggered from Nautilus and LO's .desktop file wouldn't contain X-GIO-NoFuse=true). > If I understand you right, that would not prevent the LOSS-UPDATE problem, > because LO would not request a lock from the smb/webdav server (I don't know > if that is possible). LO has two concepts of "document locking." Any given scenario can potentially use none, one, or both of these. One is to use LO's protocol of placing a .~lock.*# file next to the document. This is used for documents accessed via file, sftp, and (now) smb URLs (and when writing a file next to the document is possible for LO, i.e., when it has write access to the containing directory). This of course only prevents concurrent (i.e., potentially corrupting) modifications in cases where all parties accessing the document do so by using this protocol. The other is to use whatever locking mechanisms the URL scheme's access protocol provides: For file URLs on Linux, LO supports advisory fcntl(F_SETLK) locking. How well this works for remote filesystems (like NFS or Samba) mounted into the Linux filesystem depends on further factors. Again, this of course only prevents concurrent (i.e., potentially corrupting) modifications in cases where all parties accessing the document do so by using this protocol. For smb URLs, no such protocol is used. For webdav URLs, WebDAV's locking protocol should be used.
*** Bug 37575 has been marked as a duplicate of this bug. ***