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.

Created attachment 139994 [details]
Bug message

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.

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.

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.

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.

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

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)

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

(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.

(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.

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?

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

(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

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?

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.

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 ?

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

(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.

(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?

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'

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.

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.

(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.

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.

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.

(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.

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.

(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.

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?

(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.

(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

(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.

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

*** Bug 121678 has been marked as a duplicate of this bug. ***

*** Bug 123681 has been marked as a duplicate of this bug. ***

*** Bug 127057 has been marked as a duplicate of this bug. ***

(In reply to Thorsten Behrens (allotropia) from comment #35)

> the question is, does setting UseDocumentOOoLockFile
> to false constitute a valid workaround? -> NEEDINFO for the moment

In my case yes.

I'd just like to share that the root case of that issue is still obscure.
We have a dozen linux clients and a dozen windows clients using libreoffice
6.4 to 7.0 on two different samba 4.12 servers:

- Windows libreoffice users were never hit

- Not all linux users hit; it seems that mostly vfs mounts (like with
  gnome) never reveal the issue; while fstab/manual mounting users are
  hit more often

- The issue just "appeared" about 6 months ago, roughly when switching
  from samba 4.11 to 4.12 on one of the servers with a recent and faster
  hardware.

- On one of the samba server's I personally can reproduce the issue but
  not on the other; with the exact same libreoffice linux client and the
  exact same smbd.conf for both servers... (server's kernels and HW differ
  though).

If someone want me to do some more tests, expecially with the two samba
servers being hit/not hit, let me know.

Thanks

Many duplicates actually closer to bug 55004 point here, so I would like to mention, that https://bugs.documentfoundation.org/show_bug.cgi?id=55004#c37 helped me:

Adding nobrl to /etc/fstab was a good workaround to finally be able to save libreoffice documents to Sama cifs shares again.

*** Bug 153453 has been marked as a duplicate of this bug. ***

See my bug 156628. Still a problem in 7.5.5.2, but mounting "nobrl" is an effective workaround. I have a Fedora Linux CIFS server version 4.18.5-0.fc38. It's my (limited) understanding that BRL (bit range locking) is ignored in Linux Samba, so this issue might be specific to Linux Samba servers only. I don't have any issues with any other apps that use my CIFS shares.