Any attempt to connect via Open --> Remote files --> Add service --> Shared by Windows does not work for me, because crashes the LibreOffice. After setting up my expected connection to a Windows share, after click on OK button a pop-up windows get open, informing that open files will be recovered. After clicking OK in this form, LibreOffice restarts and a widow asking to sent a crash report is opening. I have tested this with LibreOffice 6.0.6.2 and also with LibreOffice 6.1.0.3 with the same result. I'm not quite sure whether this is really a bug or I just can not figure out how to make the link to work normally. After doing what I could, trying out the help system and searching the Internet to figure out how to link LibreOffice from Linux to the Samba server, I could not find reliable information how exactly to do it to work as expected. The connected Samba server and needed shares are perfectly accessible even by same LibreOffice 6.x via smb4k connections to same shares. My account on the Samba server has all needed rights to access write or read on the needed shares. Let say the IP address of the needed Samba server would be 192.168.1.56 Trying to connect via the IP address of the Samba server is not good explained in the help system. So I do not know shall I put in the Host field some thing like "smb://192.168.1.56" or just like "//192.168.1.56" or some thing else? In my case I have tested all possible variants I could imagine, but all such attempts lead to crash of the LibreOffice. Also I could not understood what exactly is expected to put in the field Root. Shall it work if this field is empty? All my attempts to make connection with different correctly given roots (as far I could understood it) or with empty field did not help for establishing the needed connection to the tested Samba server.
Could you give a try to https://wiki.documentfoundation.org/QA/FirstSteps? Then if you still reproduce this, would it be possible you retrieve a backtrace?
1. latest fresh/still version requirement - done. Checked with latest release versions. 2. Corrupted user profile requirement - done. Checked with erased user profile, also with initial default adjustments. All checked also in safe mode. Even have deleted the user profile and checked again without such profile (it was created by LibreOffice during startup process) 3.Graphics-related issues (OpenGL) - done. All possible CL even via script switched out, no any hardware speed-up and no any OpenGL 4.Computation-related issues in Calc (OpenCL) - not relevant. Same happens without Calc. During all above crashes still available. Please possibly instruct how to retrieve this backtrace? During all these crashes I have got a lot of *.dmp crash reports in /home/user/.config/libreoffice/4/crash/
Thank you for your feedback. About backtrace, you'll find more info here: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information
It seems to me that LibreOffice has somewhere in the code hard-coded WORKGROUP. And it is trying to connects this way to the discussed Windows (Samba) shares. But on this server where the connection is checked there is MYFILES instead of WORKGROUP. Could it be some how a reason for the reported crashes?
Unfortunately the computer where this problem exists is production computer. So setting debug mode on it is prohibited. But I will try to create a minimal virtual machine with KDE and LibreOffice and try to check under debug mode there. If the problem still exist there, then I could send you this virtual machine to check it in deep if you like. But It will take a lot of time, so it could be done during the weekend at earlyest. Also I am worrying how this could be achieved as minimal openSUSE Leap 15 will take around 15 Gb.
Searching in code with git grep -in workgroup, I don't find any "WORKGROUP". I also checked the external lib libcmis. Perhaps it's in another external lib. Before trying anything on a virtual machine perhaps some other QA member or a dev may reproduce this. As for me, I don't use Samba and don't use virtualization so can't help here, at least for this moment.
(In reply to kivi from comment #0) > Trying to connect via the IP address of the Samba server is not good > explained in the help system. So I do not know shall I put in the Host field > some thing like "smb://192.168.1.56" or just like "//192.168.1.56" or some > thing else? Just FYI (and for someone who'd decide to improve documentation): the host box gets a plain host name for Windows Share server type (like "DESKTOP-1234"); the fields are transformed *internally* to an URL like "smb://user@DESKTOP-1234/share". User does not need to specify protocol manually.
(In reply to Mike Kaganski from comment #7) > the host box gets a plain host name for Windows Share server type (like > "DESKTOP-1234") ... or plain IP (like 192.168.1.56).
Dear all, Thank you for your information. But here we have all computers on Linux. Unfortunately most of howtos expect Windows, but Linux user base is growing and may be much bigger than official reporters like IDC are reporting for Linux. Next weekend I will try this issue again and if will found some thing interesting, will report here.
(In reply to Mike Kaganski from comment #7) > (In reply to kivi from comment #0) > > Trying to connect via the IP address of the Samba server is not good > > explained in the help system. So I do not know shall I put in the Host field > > some thing like "smb://192.168.1.56" or just like "//192.168.1.56" or some > > thing else? > > Just FYI (and for someone who'd decide to improve documentation): the host > box gets a plain host name for Windows Share server type (like > "DESKTOP-1234"); the fields are transformed *internally* to an URL like > "smb://user@DESKTOP-1234/share". User does not need to specify protocol > manually. @Olivier Hallot, I thought you could be interested in this commit to improve the documentation...
Dear kivi, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear kivi, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp