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.
*** Bug 128289 has been marked as a duplicate of this bug. ***
Does RDP have any relevance to this issue? Can you check all this from a local computer? It would be great if you could experiment and narrow down the requirements and specific steps, because QA or devs will have close to zero chance setting up a similar environment. It would also be good to know if it can be reproduced with a single user relying on multiple LO installations (see [1]) instead of multiple users. And finally, as this is probably closely related to the usage of samba shares, knowing the exact configuration there would be important. [1] https://wiki.documentfoundation.org/Installing_in_parallel/Linux
(In reply to Aron Budea from comment #2) > Does RDP have any relevance to this issue? Can you check all this from a > local computer? It would be great if you could experiment and narrow down > the requirements and specific steps, because QA or devs will have close to > zero chance setting up a similar environment. Please reply to this. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information. Note also that we do not consider reports against version 6.1 at this time, so please test with 6.4.x. If you need support for obsolete versions, you have to contract someone: https://www.documentfoundation.org/gethelp/developers/
(In reply to Aron Budea from comment #2) > Does RDP have any relevance to this issue? > Can you check all this from a local computer? local computers will rarely have two users working in parallel, > It would be great if you could experiment and narrow down > the requirements and specific steps, OP wrote he downgraded to avoid data loss and user complaints, > because QA or devs will have close to zero chance setting up a similar > environment. either that should be made available (it's not very difficult), or LO should come with 'RDP not supported', > It would also be good to know if it can be reproduced with a single user > relying on multiple LO installations (see [1]) LO has enough problems with single user single installation single instance access to network shares, it's quite useless to check for problems with exotic installs while 'standard' doesn't work, > And finally, as this is probably closely related to the usage of samba > shares, knowing the exact configuration there would be important. my 'single' problems are on a network share provided by a 'FRITZ!Box' router accessed from a win7pro X64 host by 'net use x: \\AAA.BBB.CCC.HHH\fritz.nas\"device_name"\"shared_directory" "password" /user:"username"', to access it from a linux box by 'mount ... cifs ...' i had to explicitely specify the version with 'vers=1.0'? best regards, b.
(In reply to b. from comment #4) Is it reasonable for someone already having some experience here to do what you do here? > > Does RDP have any relevance to this issue? > > Can you check all this from a local computer? > > local computers will rarely have two users working in parallel, Do you say that you honestly didn't understand what was written/asked in the words you cited? that the question was about the possible distinction between some problem caused by using *RDP stack* (a possible thing) vs something which is also possible to reproduce without RDP (however unlikely that could be for a real0life scenarion, but which would enable to see that for triangers/developers in a simpler environment)? > > It would be great if you could experiment and narrow down > > the requirements and specific steps, > > OP wrote he downgraded to avoid data loss and user complaints, Did you really call the downgrade of everything (OS, LO, possibly (unknown) RDP server, too?) an answer to the direct question ("try to repro this without RDP to narrow down")? > > because QA or devs will have close to zero chance setting up a similar > > environment. > > either that should be made available (it's not very difficult), or LO should > come with 'RDP not supported', Do you really declare that QA team must never answer with attempt to help/show OP ther way to help others help OP to improve the question, and allow further work on it? Do you declare that any report must either result in "Fe found the problem and fixed it right now!" or "as you experience some problem in un(sufficiently)specified situation, we here declare the whole area (which works fine for many) unsupported"? > > It would also be good to know if it can be reproduced with a single user > > relying on multiple LO installations (see [1]) > > LO has enough problems with single user single installation single instance > access to network shares, it's quite useless to check for problems with > exotic installs while 'standard' doesn't work, Do you further call any proposed steps to limit the problem scope inappropriate, just because you you know of something unrelated? > > And finally, as this is probably closely related to the usage of samba > > shares, knowing the exact configuration there would be important. > > my 'single' problems are on a network share provided by a 'FRITZ!Box' router > accessed from a win7pro X64 host by 'net use x: > \\AAA.BBB.CCC.HHH\fritz.nas\"device_name"\"shared_directory" "password" > /user:"username"', to access it from a linux box by 'mount ... cifs ...' i > had to explicitely specify the version with 'vers=1.0'? And in the end, are you really sure that responding with such an offtopic with all that nonsense, which only cold discourage OP (or anyone else with a similar problem, who could come across and happen to be able to provide the necessary info) from collaboration and moving the bug into the good state allowing developers to further work on this, is an appropriate thing - especially for someone who seems to already have some experience... The NEEDINFO status if to receive *requested information*. If *the* information is *not* provided, then the status is still NEEDINFO. If you have a similar problem, you may provide the information. That would of course change the status to NEW (because of independent confirmation, *and* because the information was given)./ But not if you chose to "confirm" in such destructive way.
(In reply to b. from comment #4) > my 'single' problems are on a network share provided by a 'FRITZ!Box' router > accessed from a win7pro X64 host by 'net use x: > \\AAA.BBB.CCC.HHH\fritz.nas\"device_name"\"shared_directory" "password" > /user:"username"', to access it from a linux box by 'mount ... cifs ...' i > had to explicitely specify the version with 'vers=1.0'? You write about *some* problem (you didn't describe your case clearly) using very different configuration (OS of RDP host/client/possibly RDP software; possibly LO version); so have you at least attempted to confirm that that's indeed not a problem with LO version that is reported to work for OP? What makes you believe that you actually confirm the same issue?
Let me assume this is a duplicate od Samba share issue. *** This bug has been marked as a duplicate of bug 115747 ***