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
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
File opening in edit mode
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
I tested LO 188.8.131.52 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]
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.
I tried to bibisect using the tutorial https://wiki.documentfoundation.org/QA/Bibisect/Linux, but I'm facing problems:
1) I successfully cloned bibisect-linux-64-6.0 ( about 6GB).
2) git latest and git oldest give errors (error: pathspec 'latest' did not match any file(s) known to git)
3) git log displays only 3 commits, which looks strange given the 6GB of the cloning output:
Author: Jenkins Build User <firstname.lastname@example.org>
Date: Mon Feb 19 16:27:27 2018 +0100
Author: Jenkins Build User <email@example.com>
Date: Mon Feb 19 13:41:44 2018 +0100
Author: Jenkins Build User <firstname.lastname@example.org>
Date: Mon Feb 19 13:14:17 2018 +0100
4) When I use git checkout f177c04980801a81a65cec06f08ae29cc04e1a32 which should be the oldest commit and launch it with ./instdir/program/soffice, the version that opens is 184.108.40.206.0. After checking the 3 commits, all give the same version. If i understood properly the explanations, the oldest commit should be the last 5.4 version commit.
I think I'm doing something wrong. Can you help pls?
PS: I'm not a developer.
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.
Sorry for the delay of this answer.
I eventually successfully processed the whole bibisection (or at least I hope so). Here is the result:
a6e8085f7d799c6f490e1d838550d40259d8e82a is the first bad commit
Author: Jenkins Build User <email@example.com>
Date: Tue Jun 20 02:56:09 2017 +0200
:040000 040000 65e42edbbff0085c55bbe1f491696cbc8dd50d5e 73be52714a9eafbf27e0fdf34090fe864c913e5c M instdir
And here is the result of bisect log:
# bad: [f177c04980801a81a65cec06f08ae29cc04e1a32] source sha:c26995f9d725a317e9ba27310ac64f5e25bb570f
# good: [b9d78ce81dc3481fccb0cb75d76fcb6ac939cbd5] source sha:9feb7f7039a3b59974cbf266922177e961a52dd1
git bisect start 'f177c04980801a81a65cec06f08ae29cc04e1a32' 'oldest'
# bad: [96b073beb16423b65c2c5ad9368094b646471476] source sha:bbcd952c062288d9ee1efe9c786c2146abf457ea
git bisect bad 96b073beb16423b65c2c5ad9368094b646471476
# bad: [ed16f0b5571cfbb50f72be1245c698631934d635] source sha:0df16daf54696731cb3796faf0091fdfc96b65be
git bisect bad ed16f0b5571cfbb50f72be1245c698631934d635
# bad: [364aaec87b98b161517543cffda3b4402964da77] source sha:2a48fd3fbb649218f66a58e70ad904411883c63d
git bisect bad 364aaec87b98b161517543cffda3b4402964da77
# good: [7855ee79a5a3df3efd1d7fc3649f40273406f551] source sha:ec79f3453471ee9b6ae32e71ff16ea99d9b7751c
git bisect good 7855ee79a5a3df3efd1d7fc3649f40273406f551
# good: [d6c05bf73caaac35619d7764129e35ee885cd71b] source sha:3580f5a856514a8e2521f5ccf1e797bb25a19a90
git bisect good d6c05bf73caaac35619d7764129e35ee885cd71b
# bad: [42bcfde33e4057662d1717d3c013befcc2cab64c] source sha:afb8a2f49149fb407cc4a8d99a4b4a6f8a6b553a
git bisect bad 42bcfde33e4057662d1717d3c013befcc2cab64c
# good: [2762d4f470c195f2646f098d76d72cd7c24b05d8] source sha:7f793166719ce0b3917fa9751d3529c9ec5df854
git bisect good 2762d4f470c195f2646f098d76d72cd7c24b05d8
# bad: [76f756f0b03a33f96ffaddfffef08ee99da4f295] source sha:d4721434d83852102ac10ab33fae26a69eb3b1c3
git bisect bad 76f756f0b03a33f96ffaddfffef08ee99da4f295
# bad: [deff28dca96639afba62b0bb6106364672bde88c] source sha:44f4ebc0325623ed81a4021ed0d6939bd6c0c41f
git bisect bad deff28dca96639afba62b0bb6106364672bde88c
# good: [2c31c73e3a4ffc31a46d17e5b5bd5e744467ee91] source sha:7b91b815e9e170290de8ccc1da8d40a318a8dbbf
git bisect good 2c31c73e3a4ffc31a46d17e5b5bd5e744467ee91
# good: [a5bd3b5c8cf1d3420e9b903ccb82e1afa80aacb9] source sha:5471a5585cba925bb0dcb2dc41e03ad563998166
git bisect good a5bd3b5c8cf1d3420e9b903ccb82e1afa80aacb9
# bad: [a6e8085f7d799c6f490e1d838550d40259d8e82a] source sha:6ca3b3648e25ae9d4d2d29a0df83349198ec3f5e
git bisect bad a6e8085f7d799c6f490e1d838550d40259d8e82a
# good: [d55be38ca3e361b887fe4fcedaf9af775e783ca1] source sha:cab3468e96552348ae46121a490f1f6160b65213
git bisect good d55be38ca3e361b887fe4fcedaf9af775e783ca1
# first bad commit: [a6e8085f7d799c6f490e1d838550d40259d8e82a] source sha:6ca3b3648e25ae9d4d2d29a0df83349198ec3f5e
Tell me if there is any inconsistency. I can of course rerun the process.
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?
author Juergen Funk <firstname.lastname@example.org> 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)
(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)
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?
> author Juergen Funk <email@example.com> 2017-04-12 11:26:10 +0200
> committer Katarina Behrens <Katarina.Behrens@cib.de> 2017-06-06 15:58:02
> 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.
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?
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
(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
> My Steps are:
> - In samba-share right click, double-click (dolpin) on the file (*.ods,
> - 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
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:
(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?
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?
I can not open files with LibreOffice 220.127.116.11 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 18.104.22.168. 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.
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'
The results are the same as my previous comment #23.
I'm the author of
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.
I DL'd Portable LO 22.214.171.124 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 126.96.36.199 -- stuff that I cannot do with 188.8.131.52.
¤ For the saving problem,
I don't know if it's linked to this and so should be in that thread or not.
(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
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).
A) this is a regression,
B) which already had an alternate solution (SystemLocking = false),
C) and the description uses the terminology "Allow" instead of
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. ***