Bug 115747 - Can't edit file on samba shares ( see comment 28 )
Summary: Can't edit file on samba shares ( see comment 28 )
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.1.1 release
Hardware: All All
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Network File-Lock
  Show dependency treegraph
 
Reported: 2018-02-15 14:46 UTC by Jerome
Modified: 2019-01-14 17:19 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Bug message (89.99 KB, image/png)
2018-02-19 14:41 UTC, Jerome
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jerome 2018-02-15 14:46:24 UTC
Description:
When I try to edit a file on a samba share, a message is shown, saying that it's only possible to open in read-only mode because it can't create the lock file for permission reason. After downgrading to Libreoffice 5.4, all is back to normal and I can edit files normally.

Steps to Reproduce:
1.Double click on a file in a samba share in Nautilus
2.
3.

Actual Results:  
message is shown, saying that it's only possible to open in read-only mode because it can't create the lock file for permission reason

Expected Results:
File opening in edit mode


Reproducible: Always


User Profile Reset: No



Additional Info:
Ubuntu-gnome 16.04


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Aron Budea 2018-02-15 17:53:19 UTC
I tested LO 6.0.0.3 and a fresh master build (09fcdbd5e0ae35fb7db8c8784329035edd82573b) / Ubuntu 17.10, and could edit a file on a samba share without any problem.
Comment 2 Jerome 2018-02-19 14:41:22 UTC
Created attachment 139994 [details]
Bug message
Comment 3 Jerome 2018-02-19 14:42:34 UTC
I did some extra tests.

Ubuntu 17.10 + libreoffice 6.0.1

1) I tried to edit a calc sheet of a samba share located on my local network. All worked well.

2) I tried to edit the same sheet, this time from a samba share located on my work network, accessed through a VPN connection. This time, I failed like the last time with the same message. (you'll find the message attached).

So I confirm the bug. It appears only when I try to edit from a share accessed through VPN. I precise that I can edit normally the same file from the same share with Libreoffice 5.4 without problem.
Comment 4 Jerome 2018-02-21 14:32:15 UTC
One more test result:

This time, I used the same network I accessed previously through VPN and on which I had problem to edit documents with Libreoffice 6.0, but this time directly at my work place, so without having to use the VPN. The bug persists, and only with 6.0 version. 5.4 is fine. So the problem is not linked to VPN but to the relation Libreoffice/Sambashare/network itself. There is visibly one parameter on the network or on the samba server that prevents Libreoffice 6.0 to create the lock file while enabling this creation without problem for Libreoffice 5.4 ... or MS office.
Comment 5 Aron Budea 2018-02-21 20:17:43 UTC
Is there a chance you could bibisect this issue?
Bibisecting is using git bisect over successive binary builds for each source commit that are stored in a special repo. For details please see: https://wiki.documentfoundation.org/QA/Bibisect

The repo you need is bibisect-linux-64-6.0. A bit of a drawback is that it's a couple of GB in size. If you have any questions, ask away.
Comment 6 Jerome 2018-02-24 08:45:01 UTC Comment hidden (obsolete)
Comment 7 Aron Budea 2018-02-26 06:26:14 UTC
Hi, thanks for giving it a try!

(In reply to Jerome from comment #6)
> 1) I successfully cloned bibisect-linux-64-6.0 ( about 6GB).
Seems correct so far.

> 2) git latest and git oldest give errors (error: pathspec 'latest' did not
> match any file(s) known to git)
There's definitely an "oldest" tag that marks the first commit of the repo (the first commit of 6.0), but indeed the latest commit isn't tagged.
You can checkout the oldest commit like this: git checkout oldest
And the latest (which checks out master branch): git checkout master

> 3) git log displays only 3 commits, which looks strange given the 6GB of the
> cloning output:
There's a lot more than that (almost 8k commits), but 'git log' only shows as many as can fit on a screen, you can scroll by hitting space.

But let's forget that, let me sketch down the steps:

1. Check out master to make sure you're at the latest commit with: git checkout master

2. Check the commit hash (the one on top that start with "commit") with: git log -1

3. Start bibisecting with: git bisect start <latest commit hash> oldest

4. There will be 13 or so steps (each step halves the commit range). At each step repeat your bug repro steps, and type the command as follows:
- if the bug occurs: git bisect bad
- if there's no issue: git bisect good
- if the build doesn't start: git bisect skip

5. When you arrive at a single commit, post the hash "source sha" here.

If anything is still unclear, ask away.
Comment 8 Jerome 2018-03-02 08:30:37 UTC Comment hidden (bibisection)
Comment 9 Aron Budea 2018-03-03 00:42:18 UTC
Hi, thanks for bibisecting the bug, that seems like a very plausible commit indeed (referencing it below). Adding Cc: to Juergen Funk (author) and Katarina Behrens (committer).

It would be great to know how to reproduce the bug as well. It seems like the exception that happens when creating the lock file is handled change in this commit. Jerome, did a lock file get created in 5.4?

Mike, you've been dealing with lock-file-related issues lately, do you have any thoughts on what could be the culprit in this case?


https://cgit.freedesktop.org/libreoffice/core/commit/?id=6ca3b3648e25ae9d4d2d29a0df83349198ec3f5e
author		Juergen Funk <juergen.funk_ml@cib.de>	2017-04-12 11:26:10 +0200
committer	Katarina Behrens <Katarina.Behrens@cib.de>	2017-06-06 15:58:02 +0200

tdf#106942 Wrong message when lock file is empty or corrupt
Comment 10 Katarina Behrens (CIB) 2018-03-03 07:50:53 UTC
A wild guess: could it be that in case when this annoying dialog appears, samba share is mounted read-only or for another reason,  the user doesn't have permission to create files in the given folder (and since document lock files get dropped in the same folder as the document itself ... there we go)
Comment 11 Juergen Funk (CIB) 2018-03-05 07:15:30 UTC
A other possibility is, you have not rights to generate a NEW file (the lock-file is an new file), in this case it is better to carfully warn the user (i mean it is possible to ignore the warning)

Juergen
Comment 12 Jerome 2018-03-05 07:45:29 UTC
(In reply to Juergen Funk (CIB) from comment #11)
> A other possibility is, you have not rights to generate a NEW file (the
> lock-file is an new file), in this case it is better to carfully warn the
> user (i mean it is possible to ignore the warning)
> 
> Juergen

I can actually create files without any problem with other applications.
Comment 13 Jerome 2018-03-05 08:39:13 UTC
(In reply to Aron Budea from comment #9)
> Hi, thanks for bibisecting the bug, that seems like a very plausible commit
> indeed (referencing it below). Adding Cc: to Juergen Funk (author) and
> Katarina Behrens (committer).
> 
> It would be great to know how to reproduce the bug as well. It seems like
> the exception that happens when creating the lock file is handled change in
> this commit. Jerome, did a lock file get created in 5.4?
> 
> Mike, you've been dealing with lock-file-related issues lately, do you have
> any thoughts on what could be the culprit in this case?
> 
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=6ca3b3648e25ae9d4d2d29a0df83349198ec3f5e
> author		Juergen Funk <juergen.funk_ml@cib.de>	2017-04-12 11:26:10 +0200
> committer	Katarina Behrens <Katarina.Behrens@cib.de>	2017-06-06 15:58:02
> +0200
> 
> tdf#106942 Wrong message when lock file is empty or corrupt

After checking, I confirm that a lock file is definitely created with 5.4.

Regarding reproducing the bug, the simplest way may be to create you a VPN access to a specific test folder on our file server. I'll ask our sys admin, but will be able to do so only tomorrow.
Comment 14 Jerome 2018-03-13 14:33:36 UTC
Hello,

I've just received the answer of my sys-admins to open the new VPN connection for you. They are not very hot for this option (to say the least) for security reasons.

So how could I help you? Do you need me to communicate you any samba, network or other setting file?
Comment 15 Juergen Funk (CIB) 2018-03-23 10:38:04 UTC
Hi  Jerome,

my admin installed a samba-share, i have used the current build 751191ed2d7d6 (debugmode)and kubuntu 16.04 using Dolphin, but i can't reproduce you problem, in my case it generate the lock-file and no message appear.

My Steps are:
- In samba-share right click, double-click (dolpin) on the file (*.ods, *.odt)
- Libreoffice open the file (content are only 3 lines)
- i see the look file
- no message and can edit, save

Other step: Open the file in Libreoffice from the smaba-share no problem


The only diffrent tu your testcase is Dolphin


juergen
Comment 16 Jerome 2018-04-17 17:49:47 UTC
(In reply to Juergen Funk (CIB) from comment #15)
> Hi  Jerome,
> 
> my admin installed a samba-share, i have used the current build
> 751191ed2d7d6 (debugmode)and kubuntu 16.04 using Dolphin, but i can't
> reproduce you problem, in my case it generate the lock-file and no message
> appear.
> 
> My Steps are:
> - In samba-share right click, double-click (dolpin) on the file (*.ods,
> *.odt)
> - Libreoffice open the file (content are only 3 lines)
> - i see the look file
> - no message and can edit, save
> 
> Other step: Open the file in Libreoffice from the smaba-share no problem
> 
> 
> The only diffrent tu your testcase is Dolphin
> 
> 
> juergen

I have forced the oppening of a special and limited VPN for you on our file server. I'll switch on your personnal Email to send you the credential files
Comment 17 Aron Budea 2018-04-22 14:17:34 UTC
Jerome, is it possible that certain characters aren't allowed in the file name, that's why lock file creation fails? (similar to bug 116420)
Can you try creating such a file manually?
Comment 18 skoworodker 2018-05-11 15:01:47 UTC
I have similiar bug.
I have a folder that containst files, in which only write to. I have no permission to create new file into a folder for security reason.
If i open file in LO 6.0.4, win10 x64 - i see same error (russian text, in my case).
In my opinnion LO cant create .lock file in same folder, and wont create it in some temp folder.
In previous version (eg 5.4.3) LO dont create .lock file too, but still open file for read\write. Maybe .lock file create in some temp folder.
Comment 19 Xisco Faulí 2018-11-28 09:50:33 UTC
Based on https://ask.libreoffice.org/en/question/174111/cannot-save-file-or-create-lock-on-file-on-samba-server-from-windows-7/ and many other question on Ask, increasing the severity/priority

@Juergen Funk, any chance you could take a look at this issue ?
Comment 20 Lena 2018-12-05 05:56:56 UTC
We have the same. We can open and edit file, but can't save them because get error "Unable to create tmp file".

Samba share mounted from /etc/fstab with following string:

//os-srv/public /mnt/samba cifs uid=nobody,noperm,file_mode=0777,dir_mode=0777,credentials=/usr/local/etc/samba/smbcredentials,iocharset=utf8,sec=ntlm 0 0

Other programs like mousepad or another works fine. Ancient LibreOffice 5.1.6 from Ubuntu repo works ok.

Versions we have:
Ubuntu 16.04
LibreOffice 6.1.3
cifs-utils 6.4-1ubuntu1.1
samba 4.3.11+dfsg-0ubuntu0.16.04.18
Comment 21 Jerome 2018-12-05 08:09:25 UTC
(In reply to Aron Budea from comment #17)
> Jerome, is it possible that certain characters aren't allowed in the file
> name, that's why lock file creation fails? (similar to bug 116420)
> Can you try creating such a file manually?

Hi Aron,

Sorry, I had missed that message. No, it's not name related. I use standard ascii names. Moreover, what is important there is that with versions older than 6.X, everything is running smoothly.
Comment 22 Aron Budea 2018-12-05 16:44:56 UTC
(In reply to Jerome from comment #21)
> Sorry, I had missed that message. No, it's not name related. I use standard
> ascii names. Moreover, what is important there is that with versions older
> than 6.X, everything is running smoothly.
It's not related to the name of the file, but to the name of the lockfile. If you have a file named "xyz.odt", the lock file is named ".~lock.xyz.odt#", could you please check if you can create a file named like that lock file directly?
Comment 23 chuck.pobanz 2018-12-05 17:20:58 UTC
I can not open files with LibreOffice 6.1.3.2 on a samba share from my Linux Mint Client. Samba share is from ubuntu 16.04 server. Everything works fine from windows 7 client with LibreOffice 6.1.3.2. However from Linux mint 18.3 client file will not open. It takes about 15 seconds, then crashes. I can copy files to and from the server with Linux mint Nemo (file manager). I can open and modify files with my text editor, but not with LibreOffice.
Comment 24 Katarina Behrens (CIB) 2018-12-07 11:13:22 UTC
Workaround (not to be used on mission-critical samba shares, it's really just that, a workaround):

Go to Tools > Options > Advanced > Expert configuration
Search for 'UseDocumentSystemFileLocking' and 'UseLocking' keys
Set 1st one to 'false'
If it doesn't help, set also 2nd one to 'false'
Comment 25 chuck.pobanz 2018-12-08 06:27:34 UTC
In response to comment #24, making these changes is not a work-around for me. I still can not edit files on my Samba share. I have tried setting both of them, 
Tools > Options > Advanced > Expert configuration > 'UseDocumentSystemFileLocking' 
     and 
  'UseLocking' keys
to 'false'
The results are the same as my previous comment #23.
Comment 26 [REDACTED] 2019-01-08 09:56:06 UTC
oHi,

I'm the author of
https://ask.libreoffice.org/en/question/174111/cannot-save-file-or-create-lock-on-file-on-samba-server-from-windows-7/
I cannot read nor save any file from/to the samba server I use.

¤ For the lock-on-file problem,
I saw that the generated lock files start with a dot,
but I'm not allowed to create any file starting with a dot on the samba server I'm using.

Now,
I DL'd Portable LO 5.4.7.2 on my Windows 7.

Opening a locale .ods file, it creates a temp lock file in the same directory.
Opening a remote (samba) .ods file, it doesn't create the temp lock file (? at least, no file are created in the same remote directory).

So I can open and save file from my samba server with 5.4.7.2 -- stuff that I cannot do with 6.1.3.2.


¤ For the saving problem,
I don't know if it's linked to this and so should be in that thread or not.

Thx.
Comment 27 Aron Budea 2019-01-08 10:59:18 UTC
(In reply to noreply+69732 from comment #26)
> I cannot read nor save any file from/to the samba server I use.
Hi! What kind of samba server do you have? Do you know of a specific setting that prevents the creation of files starting with dot? As far as I could see this is normally allowed both on Windows shares and Linux samba shares.
Comment 28 Justin L 2019-01-11 12:37:23 UTC
The problem can be replicated by adding this share setting
  veto files = /.*/
and restarting the samba server.

Doing that, I can confirm that comment 9 has identified the correct commit.
Comment 29 Thorsten Behrens (CIB) 2019-01-11 13:34:21 UTC
Since all versions since the dark ages try to create lock files also on samba shares, that means in pre-6.0 versions the error in writing the lock was simply ignored.

With that, I tend to consider this NOTABUG.
Comment 30 Thorsten Behrens (CIB) 2019-01-11 13:38:58 UTC
(In reply to Katarina Behrens (CIB) from comment #24)
> Workaround (not to be used on mission-critical samba shares, it's really
> just that, a workaround):
> 
> Go to Tools > Options > Advanced > Expert configuration
> Search for 'UseDocumentSystemFileLocking' and 'UseLocking' keys
> Set 1st one to 'false'
> If it doesn't help, set also 2nd one to 'false'

There's also UseDocumentOOoLockFile which I think is the one that disables writing those lock files. Might be a suitable work-around here.
Comment 31 Justin L 2019-01-11 13:54:05 UTC
I have no idea why so much code was removed from the exception clause, but restore the part with "if ( bUseSystemLock || !IsOOoLockFileUsed() )" solves both the read-only problem on loading, and the save failure.
Comment 32 Thorsten Behrens (CIB) 2019-01-11 14:05:46 UTC
(In reply to Justin L from comment #31)
> I have no idea why so much code was removed from the exception clause, but
> restore the part with "if ( bUseSystemLock || !IsOOoLockFileUsed() )" solves
> both the read-only problem on loading, and the save failure.

Because that hides the fact that the lock file could not be created. If in a deployment people are ok to only use system file locking, the config option UseDocumentOOoLockFile should be set to false.
Comment 33 Mike Kaganski 2019-01-11 14:39:03 UTC
Is there an option to use locking if possible, so that the lockfile can help on filesystems which allow that, and still be able to work with those filesystems that don't? or do we have only all-or-nothing option?
Comment 34 Mike Kaganski 2019-01-11 17:43:56 UTC
(In reply to Thorsten Behrens (CIB) from comment #32)
> (In reply to Justin L from comment #31)
> > I have no idea why so much code was removed from the exception clause, but
> > restore the part with "if ( bUseSystemLock || !IsOOoLockFileUsed() )" solves
> > both the read-only problem on loading, and the save failure.
> 
> Because that hides the fact that the lock file could not be created. If in a
> deployment people are ok to only use system file locking, the config option
> UseDocumentOOoLockFile should be set to false.

In my opinion, the original fix (and this comment) somehow change the proper notion of a feature/function that helps to reach some goals (reliably detect locking/identify locking person) to a requirement for function (=if we cannot detect locking reliably, then fail to work). Is that what is intended? and what exact problem was solved by that change, that justifies making this enforcement? The original problem in tdf#106942 only mentioned a corner case of "drive full", which could be detected separately and acted accordingly.
Comment 35 Thorsten Behrens (CIB) 2019-01-12 01:04:10 UTC
(In reply to Mike Kaganski from comment #34)
> In my opinion, the original fix (and this comment) somehow change the proper
> notion of a feature/function that helps to reach some goals (reliably detect
> locking/identify locking person) to a requirement for function (=if we
> cannot detect locking reliably, then fail to work). Is that what is
> intended? and what exact problem was solved by that change, that justifies
> making this enforcement? The original problem in tdf#106942 only mentioned a
> corner case of "drive full", which could be detected separately and acted
> accordingly.

That's a fair statement wrt. the scope & wording of the fix. But I conversely consider a setup where arbitrary shell globs of files cannot be written a corner case - the question is, does setting UseDocumentOOoLockFile to false constitute a valid workaround? -> NEEDINFO for the moment
Comment 36 Justin L 2019-01-12 06:57:10 UTC
(In reply to Thorsten Behrens (CIB) from comment #35)
> the question is, does setting UseDocumentOOoLockFile
> to false constitute a valid workaround?

From a testing perspective, the result is that files can be saved (no warnings, just a save as normal). Opening files result in a warning and read-only mode.

(P.S. no "user" will be able to answer questions about what is an acceptable work-around.  Now we have at least 3 variables related to locking - how can anyone know what the implications of any of this are, especially when no definitions have been given? Based on comment 19, this is not a "rare" case, so it would be really hard to determine if preventing ANY use of a dotlock file is valid in every case.)

It seems like your concern already had been addressed. Wasn't setting UseDocumentSystemLocking = false a good enough workaround for those who want to require the existence of a lock file? (Perhaps not - I'd guess that the benefit of ALSO using a system lock is that the user CANNOT override it, like they CAN do with an OOo lock file. Probably also worth noting is that it isn't checking if the system SUCCEEDED in using it's own locking mechanism, only that it would try...). 

UseDocumentSystemFileLocking: Allows to specify whether the OOo document file locking mechanics should use the system file locking (default true).

UseDocumentOOoLockFile: Allows to specify whether the OOo document file locking mechanics should use the lock file for locking (default true).

UseLocking: Allows to specify whether locking should be used at all. Use this setting only for debugging purpose (default true).

UseWebDAVFileLocking: Determines if WebDAV-specific file locking is used for documents on WebDAV shares. It is not recommended to set this option to 'false' in scenarios where multi-user, concurrent read/write access to WebDAV share is required (default true).


Because 
A) this is a regression, 
B) which already had an alternate solution (SystemLocking = false),
C) and the description uses the terminology "Allow" instead of
"Mandatory",
D) involving an unnecessary file for normal operation,
E) caused by undocumented rationale for the changed behaviour,

I suggest reverting this bit and introducing a MandatoryLocking variable to handle the very unique situations where locking files actually have any value.
Comment 37 Xisco Faulí 2019-01-14 10:10:22 UTC
Discussion moved to the dev mailing list for wider audience -> http://document-foundation-mail-archive.969070.n3.nabble.com/Re-Bug-115747-Can-t-edit-file-on-samba-shares-td4255934.html
Comment 38 Xisco Faulí 2019-01-14 17:19:53 UTC
*** Bug 121678 has been marked as a duplicate of this bug. ***