<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - deleting file when concurrent access from the same host"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=127057">127057</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>deleting file when concurrent access from the same host
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>6.1.5.2 release
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>bugs@atina-asso.org
</td>
</tr></table>
<p>
<div>
<pre>hi there,
Context :
our organization counts 100+ users with desktops or laptops all on
Debian-stable OS, previously Debian 9 Stretch and we plan to move to Debian 10
Buster.
A large amount of business documents are on multiple network shares exposed by
classic samba/ADDC and users/groups permissions management.
Our off-site and on-the-go workers are using RDP connections to our head-office
platform, driving them to a farm of 3 RDP servers in which they run a seemingly
identical desktop environment than on native devices.
Each of these RDP host run the exact OS and software stack than our native
desktops, with the only difference being their multi-users environment
settings, so that they can each host more than 10-20 simultaneous users.
Whether it is on native desktops or on RDP servers, LibreOffice is on the exact
same release, that is to say 5.2.7.2 under Debian 9, and this architecture
worked perfectly well for all our users since 4 years.
We plan to move soon to Debian 10, providing LO 6.1.5.2, and have encountered
no problems on workstations until now after few weeks of tests and staged
deployment.
This week we upgraded our 3 RDP servers with confidence but encountered almost
immediately a bunch of complaints from some users who lost files by using LO as
usual.
Problem :
After analysis it appears that under the updated environment (Buster + LO 6.1),
when an user open a remote file with LO (tested with Writer and Calc) on a
network share, he can work normally on the file until someone else on the same
host (RDP server) open the very same remote file. That second user is welcomed
with the standard LO dialog-box ("warning, file already opened by X") where he
could choose to open the file in read-only mode, after what all seems OK.
Except that from that time, the file being opened by 2 users on different
sessions within the same host, if the first user made a modification and wants
to save it, LO shows an error saying that the original file doesn't exists
anymore and that it can't be recorded. Surprisingly when we (sysadmin) look at
that same time into the share, the file is physically present.
Even more surprising and seriously troublesome, if the second user close the
file (that he was read-only viewing) then it is immediatly deleted from the
share for real and without any warning !!!
>From that, the first user has still the original representation of the document
opened in his LO, but can not record it (file doesn't exists error), except if
he goes to 'save file under...' option and manually sets another filename or
destination.
Many users ran under kernel panick when viewing these errors, and as a result
overwhelmed our hotline since yesterday. And even worse, the others users
didn't bother or noticed that files were deleted, and so could eventually lead
to a permanent data loss for the organisation (we can't restore a file if we
don't know it is lost).
This behaviour was only reproductible when concurrent users were on the same
host, if user 1 was on RDP server A and user 2 on RDP host B or C, then it's
all good (lock file, read-only access, no silent file suppression, tested with
the same files under the same network shares with the same user permissions).
Not having this erratic behaviour on previous environment we decided to quickly
downgrade our 3 servers to Debian 9 with LO 5.2.7.2.
Any help is welcomed, thanks.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>