Linux : SMB shared folder's LO documents in RW without overriding security

English
#1

Hi all :slight_smile:

Sorry for the very long title but I do not found a way to shorten it.

We have a NAS which share some Samba folders in heterogeneous machine’s parc Windows and Linux (Debian and Ubuntu).

From some Linux distros and particularly those with the XFCE4 Desktop Environment with its native files manager thunar application, we have some problems to open LO documents (ods, odt, odg) directly from SMB shared folders which trigger this message box :

“Document file xxx is locked for editing by : Unknown User ; Open document read-only or open a copy of the document for editing”.

As I did not find a way to allow a RW document opening, I developed a bash script which auto-mount all SMB shared folders the user has the access rights. It works very great as the user can modify the documents with the impression to work locally.

Note : for your information, from what I understood, with Debian 11 Bullseye with XFCE4 DE, for modify from the SMB shared folder, the prerequisites packets are gvfs-backends (network access) and gvfs-fuse (ability to open a document from a SMB shared folder)

Recently as I needed to adapt this script to work in multiple users environment and as I had so problem to achieve this, I came back to the origin’s problem and now it seems to me more clear.

I read in a lot of threads that the solution was to disable the LO UseLocking property (like this one) which prevent the lock’s file creation … and this works, but in creating a problem with the concurrent accesses of documents (what happens if someone tries to modify a document that is already being edited ? - like supposed by this thread). I think in this case my approach of automount script is more relevant.

I suppose there a better fitted solution to make the LO document openable directly from share in keeping its security .

What is it ?

With adelphity,
lnj

#2

The user needs to have the right to create the lock files.

#3

Hi

I am not sure to understand your answer …

What right are you talking about ?

The users I am talking about have the rights to create / delete / modify for files / folders.

#4

Lock file

#5

Then I don’t understand what’s going on.

#6

Me too, this is why I asked some help and why I detailled my problem with accuracy.

Yes I confirm the users have the rights to read and write in those SMB shared folders so LO can create itself the lock files.

I am sorry but LO have some problematic bugs not resolved at this day so I try to make a workaround before the LO crew correct it (if she do it a day).

#7

@Hrbrgr
Your link reminds me an idea that I had and forgotten, to make the same thing that LO do (ie. overide LO to autocreate a locked file for each opened document).

So I edited a lock file and discovered it contains basically :
,USER,HOST,DATE,LO_PROFILE_FILE;

In this case I would disable the lock file property from LO and manage it myself.

Is it possible to make that ?

#9

Sorry ! I believed this forum was for both LibreOffice single and advanced users. I am not considering myself as advanced but as my need is advanced because I try to workaround a LO bug this thread may seem surely a little confuse.

Yes I will try this, but I am not sure of its complete feasibility that is why I asked opinions.

What I imagined is to disable the LO locking process, create myself this lock file from both Linux desktop launchers and LO document open event, to delete it on the LO document close event. So a concurrent opening is not possible and the data security preserved.

I will let the thread opened if someone have a better idea and expertise than mine on this subject.

#10

I use documents from a Windows share on a daily basis. There must be something special with your setup. Can you really log in as user and create a new file in the directory? I suspect that a Samba share on a Linux system has more restrictive default settings than ordinary Windows servers use to have.

#11

Unfortunately, writing to SMB/CIFS shares (actually NFS was also pretty bad too) from LO with file locking has always been a rough situation, especially in heterogeneous OS pools of machines, and sometimes highly dependent on the version of CIFS implemented at the server. These problems already existed with OpenOffice.org back in version 2.0. The fact that they are still around shows that not much interest exists in the developer community to solve them.

#12

An issue does not exist before it has become reproducible. A developer can not fix any problem that is out of reach. I can reproduce a similar issue when I disallow creation of new files for the containing directory while the files have read/write access. This is because LO can’t create the lock file and therefore opens the file in read-only mode.
Do you have any hidden lock files in that directory? They may be residues from previous failures or crashes.

#13

As I was looking for arguments to prove to @Villeroy that this is a real problem that I did not invent, I found this thread (which I must have read in the past but without understanding the relevant parts) where @oweng describes a detailed solution to open an LO document from an SMB share (however in a different KDE related context) in evoking the libreoffice-gnome package which would be a dependency too and the last post before the thread closes confirms that installing it solved the problem. So I tried it … with success and the creation of lock files works too :grin: !

[edit]I just discovered there is different comportment from the way we open the document : with double click (the document opens normally) or with right click (the message box “Document … is locked for editing” displays - see above). So a minor side effect that I still wanted to point out[/edit]

From QEmu virtualization, a new fresh Debian Buster or Bullseye last version system just installed and the last version of our NAS openmediavault 6.0.32 (with a user, a shared folder with RW rights for the user, a SMB share to this shared folder and the SMB service on). So no, nothing special.

Yes. As I said in my first post I had created a workaround based with SMB shares auto-mounted which works very well and when a user opens a LO document, the bound lock file is created at the same time, and is removed when he close the document.

Yes I think you are right. But if we can contribute to point the origin of problem, maybe they will investigate it better. I will test more to see if the following packages are sufficient for others Debian versions and I would too love to understand why there is a disparity on Linux distros and the Desktop Environments. Finally I would to debug what is going on when LO starts and immediately stops (like it starts, we can surely see why it stops).

Is it possible to test if the 3 packages are sufficient for your fresh system and make a return ?

#15

I wouldn’t say your installation has “nothing special”. You chose Xfce desktop (which is perfectly legitimate). However this implies you install also all dependencies. Not all of them are enumerated in the package requirements. Some of them are called “weak dependencies”, meaning an application may work albeit in a degraded condition.

You probably met such a limitation. LO need wrapper packages to interface smoothly with its environment, e.g. for the widgets X11, GTK+ or KF5. The same holds true for the virtual filesystems, notably gvfs which seems to be required for SMB.

The fact that the package is named libreoffice-gnome shows that the issue lies in some incomplete implementation by the distro maintainers to bring functionalities present in GNOME but not natively in Xfce. There is no such package in Fedora, suggesting that the I/O library is complete and self-sufficient.

Don’t blame the developers. They are busy enough with “internal” LO bugs and they may be forgiven for missing a contextual issue. There are thousands distros out there (not counting Window$ and MacOS) and these distros are user-customisable in infinite variants. They can’t test every possible configuration.

Glad you found a solution by yourself. But as @Villeroy rightfully remarked, a problem exists only when it is reproducible. In your case, it was difficult because that needed detailed knowledge of work station configuration (all installed packages) and detailed description of server configuration. … and some familiarity with the workflow.

#16

@ajlittoz
Thanks you for this detailed inventory. I do not want really blame developers (to be honest I was part of this profession years ago :wink:) they give us a fantastic service, but as I try little by little to introduce open source into the habits of users for leaving the Microsoft world, I get really annoyed when a native Windows feature just does not work on Linux (in my opinion it’s this kind of thing that discredits Open Source communities and that makes ordinary people prefer to pay to have a service - which will not necessarily work without problem, we agree !).

From my own experience for the few detailed troubles I reported in the Open Source sphere, nobody answered to me or investigate. So I desperate to report a problem and I try by myself to build a workaround.

#17

So to summarize, from what I understood, to allow managing LO documents with thunar file manager directly from SMB shared folder (tested in Debian Buster and Bullseye fresh systems with success), we need to install the following dependencies : gvfs-fuse (ability to manage a file in a GVFS from LO), gvfs-backends (ability to access a file in a shared folder) and libreoffice-gnome (ability to manage a document in a shared folder from LO).

#18

Is libreoffice-gnome really necessary, or would gvfs-fuse and gvfs-backends already be sufficient?

That’s a very narrow view. Thousands of fixed or even only triaged reported bugs indicate differently.

2 Likes
#19

Yes I confirm it ! libreoffice-gnome is necessary with Buster|Bullseye - XFCE4 - thunar to make LO manage documents from shared folders, but it seems illogical as this package permits to the GVFS access from GIO API (source) whereas the package gvfs-fuse permits access from FUSE. It is very confusing …

Also I wanted to make notice that the pcmanfm package (another file manager) installs itself the gvfs-fuse and gvfs-backends dependencies but the libreoffice-gnome package seems not to be the only necessary package to make this application to run like thunar (but I would not investigate more).

After installing the strict necessary I determined that the libreoffice-gnome package is sufficient without its dependencies. So I want to investigate in this package to find the part of code which is necessary to make LO managing correctly files from shared folder. I suppose it works with a library. Where can I find this code ?

#20

As Debian -- File list of package libreoffice-gnome/bullseye/amd64 lists
/usr/lib/libreoffice/program/libucpgio1lo.so
that would be gio - OpenGrok cross reference for /core/ucb/source/ucp/gio/ but I don’t see how that would help you.

#21

As this package seems not dedicated exclusively to the management of shares with GVFS, I imagined isolating the reduced code which allows this management in order to understand what is happening under the hood to reproduce it outside of LO. But you are right it will not really help me and it seems more complicated than expected. Thanks anyway :wink: !

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.