Bug Hunting Session
Bug 56544 - FILEOPEN: Lock file is not created on samba share (via gvfs)
Summary: FILEOPEN: Lock file is not created on samba share (via gvfs)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.5 release
Hardware: All Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA target:5.2.0 target:5.1.2 target:...
Keywords: dataLoss
: 37575 65855 (view as bug list)
Depends on:
Blocks: File-Lock
  Show dependency treegraph
 
Reported: 2012-10-29 20:56 UTC by Zsolt Szokolai
Modified: 2017-12-07 07:23 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zsolt Szokolai 2012-10-29 20:56:17 UTC
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
Comment 1 Zsolt Szokolai 2012-11-11 09:45:11 UTC
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.
Comment 2 sasha.libreoffice 2012-11-15 11:40:30 UTC
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
Comment 3 walid 2012-12-22 05:31:42 UTC
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
Comment 4 Owen Genat (retired) 2013-08-18 10:22:47 UTC
*** Bug 65855 has been marked as a duplicate of this bug. ***
Comment 5 Rik Shaw 2013-12-10 22:15:50 UTC
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
Comment 6 Rik Shaw 2013-12-10 22:17:55 UTC
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?
Comment 7 Maxim Monastirsky 2013-12-11 08:01:06 UTC
(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.
Comment 8 Rik Shaw 2013-12-13 02:12:36 UTC
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*.
Comment 9 Owen Genat (retired) 2014-01-27 21:55:17 UTC
Summary edited for clarity.
Comment 10 Joel Madero 2015-05-02 15:43:51 UTC Comment hidden (obsolete)
Comment 11 raal 2016-02-03 17:56:11 UTC
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
Comment 12 Vincent Lucy 2016-02-10 08:54:08 UTC
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
Comment 13 Tim Banchi 2016-02-10 12:27:44 UTC
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
Comment 14 sophie 2016-02-10 15:40:06 UTC
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
Comment 15 Vincent Lucy 2016-02-11 15:42:06 UTC
@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
Comment 16 Commit Notification 2016-02-11 17:29:17 UTC
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.
Comment 17 Stephan Bergmann 2016-02-11 17:47:36 UTC
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/>).
Comment 18 Tim Banchi 2016-02-11 19:22:39 UTC
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
Comment 19 Commit Notification 2016-02-11 20:35:13 UTC
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.
Comment 20 Commit Notification 2016-02-11 20:37:29 UTC
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.
Comment 21 Commit Notification 2016-02-15 20:03:13 UTC
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.
Comment 22 Stephan Bergmann 2016-02-16 09:00:25 UTC
(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.
Comment 23 Jean-Baptiste Faure 2016-02-21 16:31:46 UTC
*** Bug 37575 has been marked as a duplicate of this bug. ***