Plasma is getting worse in integration with corporate networks or intranets

I’ve been using Plasma for more than 10 years (since it was KDE) always with openSUSE. At home for many more years, but I decided to try it at work, where we have a proxy network that requires authentication, and after the jump to Plasma 6 (even before) I will have to abandon the use of Plasma (and therefore a Linux desktop) in my work environment.

It’s been years since I opened several threads reporting KDE’s problems with network integration where SMB, FTP, FISH and other services need to be accessed, but still no progress at all. I had to find my own way to get the KDE desktop to work in proxy environments that require authentication, using PAC files. The problems are several and critical:

Access to Samba shared resources
Accessing shared resources in Windows domains becomes difficult. When using dozens of Samba resources, which may be required from time to time, it is not logical to have to create fstab accesses for those resources. One prefers to use them as in Windows: Type in the URN (\server\path) and add it to favourites. Well, the KDE desktop asks for username and password every time you access those SMB folders (in same session), instead of saving it. But the worst thing is that if a file is opened from this shared resource, the desktop session is closed, and from the application with which the file was opened, the user tries to open the file again from “Open recent”, and then the user tries to open the file again from “Open recent”, the file cannot be located. Of course, there are threads with such a bug (mine at least) explaining why.

HTTP proxy management with authentication: From bad to worse
Proxy management in Linux environments has two parts: the one configured in the chosen Linux system, which depends on the distribution, and the one configured in the desktop environment.

In my case, the proxy configuration of the system works perfectly, even allowing to enter the user and password (hidden) for the proxy, so that the system update operations and any other program on the system that requires Internet access, works transparently. Since access to local servers does not require going through the proxy, the IP ranges that do not need to be accessed through the proxy are also specified. The exceptions in the use of the proxy, work correctly, being able to access through console FTP to local IPs without going through the proxy.

The KDE desktop proxy settings (and I say “KDE desktop” instead of “Plasma” because these problems have been going on for almost a decade now) are not so simple anymore. If I use the “Use system proxy settings” option and when I click “Show environment variable values”, the same system proxy values are displayed. However, if I go to Dolphin and try to access the same FTP server (using its IP) that I accessed from console, Dolphin shows the error “Could not connect to machine 10.162.0.20: The proxy type is invalid for this operation”, i.e. KDE totally ignores the NO_PROXY environment variable.

Moreover, if I access the KDE desktop settings and try to download some add-ons (new mouse pointers, wallpapers, window decorations, etc) it is impossible to do so, because when I click the download button, a KDE window appears “An error has occurred. Failed to load providers from the file https://autoconfig.kde.org/ocs/providers.xml” (the URL is one of many that appear, depending on where in the configuration we are trying to download new content). That is, KDE tries to access that URL without using the proxy. But also, if KDE was trying to use the proxy, it would ask me for user and password, and it doesn’t do it.

As I had already mentioned, this problem with proxies is ALWAYS, more than a decade and seeing that for KDE was not a priority to solve the issues I opened about it, I managed to create a PAC file and solve at least the problem of access to local FTP services without using the proxy. That file is of course put in the KDE proxy configuration, under “Use proxy configuration URL”. And so I managed at least to solve the problem of FTP access to local servers. But the latest Plasma updates (since more than 4 months ago) have messed up even that trick, and I can’t FTP to local IPs using the PAC file anymore either. Dolphin shows the message "Dolphin could not connect to machine 10.162.0.20".

For the problem of not being able to download mouse pointers, backgrounds, etc, I never found a solution, so when I needed to download a plug-in or anything else from “System Preferences” I had to download it “by hand” from another system and take the file to my computer which requires a proxy.

However, when launching “Discover”, it does ask for user/password (of the proxy) as it should do (and allows to save the password), something that is inconsistent with the operation described so far.

However, when launching “Discover”, it does ask for user/password (of the proxy) as it should do (and allows to save the password), something that is inconsistent with the operation described so far. But what’s more, if I search for “Filezilla” in “Discover”, it finds it and tells me that it is available from my distro’s repository. If I click “Install”, it throws an error window “The repository is not available”. If I do the same from my distro installer, the repository is perfectly available.

I add that once “FileZilla” is installed, it works flawlessly to access my local FTP servers, without any problem or added configuration.

Conclusion
And that’s it. I had to write this because a few days ago, in another thread where a user was complaining about “Plasma 6”, a moderator commented about opening bug reports, and I just couldn’t take it anymore. After many, many years with bugs that perpetuate or get worse over time, on more than one occasion a developer has commented that the problem was not considered “a priority”. Perfect. With such a problem-solving policy, not only does KDE get rid of your desire to report and document bugs, but it will never penetrate the niche of enterprise computers. I, clearly after what has been explained, can no longer recommend in 2024 the use of the KDE desktop instead of Windows to anyone who wants to use it on an intranet, no matter how small, and that’s a pity.

Thanks for reading me

7 Likes

I don’t have experience with proxies, but for accessing shares smb4k solved most of my problems. But I won’t lie, I miss the convenience of using network shares on Windows.

I have been using cntlm for years to solve the problems of enterprise proxies while working with openSUSE Tumbleweed and KDE Plasma.
However, I have recently changed job and I do not have to suffer an (Windows-based) enterprise network environment anymore, so I can offer no help regarding the use of Plasma 6.

Thank you for your experience, Cris. I tried that local proxy you mentioned, but it didn’t solve the problem, because as you may have read in my message, the problems go beyond that. There are KDE applications that do ask for proxy user and password (Discover, for example) and the rest, simply give error when accessing the internet. Or - for the most part - they absolutely ignore the rules set in “no_proxy”. And since the update at the end of last year, ignoring the PAC file rules is the last thing that makes it impossible to work seriously with Plasma.
It is relegated to a desktop like any other, when it was the only Linux desktop that was possible to integrate - with great difficulty - in corporate Intranets.

Thank for sharing your experiencie. smb4k is a “reasonable” - though not problem-free - solution in a home network where you have some shared folders. But for something more serious where you work with shared folders on an ad hoc basis, it is not the solution.

Yes, it’s sad unfortunately.
One last thing though: IIRC I solved the “no proxy” problem by using no-proxy rules in the config file of CNTLM, instead of relying on the no_proxy environment variable.
I hope this can help you.

Thanks again for your suggestion Cris. Unfortunately, CNTLM is a project that has not been maintained for many years and being something critical (it manages the input and output of information) the fact that it does not even receive security updates makes me discard its use.

The underlying problem is that, as you did and as I have done so far, KDE does not solve problems that have existed for many years and were not supposed to happen. It is a lack of interest to solve them because although they are difficult to reproduce environments, I understand that before implementing such features in their products should check all possible scenarios and, if they can not do it, here we are the users who report such failures that we are willing to collaborate to solve them … but as you can see in the threads of the reported bugs, there are no questions about it from the developers. Years go by and see if “magically” the problem has been solved in a new version. It’s hopeless.

1 Like

I’m not sure if this will help or not. The way I got around this was to first create a “Network Folder” for the Windows share in Dolphin, which creates a .desktop file. Then I edit the .desktop file so that I embed the password right into the URL or whatever it’s called. Like:

smb://user:password@server/pathroot/path

Then I can just click on it and I’m in without a password prompt.

Hello michaell

Yes, that’s the way I use it and the way I add it to my bookmarks (in Dolphin and Krusader). In itself, connecting to SMB folders is not a problem. The problem is the way KDE connects to those folders. I opened a ‘bug’ about it (which of course, is still unresolved) and I’ve already mentioned it in my first post: If you try to open a file located in an SMB folder in another new session (for example, a file you opened yesterday in LibreOffice Writer) and today you want to reopen it from ‘File, Recent Documents’. you will not be able to do so. It will fail, because of the way KIO establishes the connection. It is a different path in each session.

2 Likes

This is such an important part of KDE, I’m wondering if your concerns should be made visible through the “KDE Goals” proposals? That way the entire community can see this and vote on it to hopefully make it a priority for the next year.

1 Like

Thank you Michaell. I have even further refined the problems I have already mentioned here and clarified exactly how to reproduce them, isolating in two separate threads each of them, as although they are related, they seem to be ignored by the developers (they don’t even ask you or ask you to do additional tests).

I understand that it is difficult to reproduce the cases, as corporate environments are more difficult to replicate, but this is not the case. It is a proxy with http validation that is the only thing you need to have enabled. I don’t think KDE doesn’t have the means and staff to replicate something like this.

In any case, that’s what I’m available for and no further information is required from KDE.

1 Like

I’m following this thread as I work closely as the only KDE user in our company. In Plasma 5, there was an option to save a fallback SMB username and credentials in the global settings, but this feature was removed with the comment that it was unnecessary. I found it quite useful, and now I’m facing the same issue as you.

We frequently work with various NAS devices during events, and I don’t have the convenience of adding everything as bookmarks each time. Every time I access a smb folder, I am required to enter my credentials, which is frustrating and has become a new challenge in Plasma 6.

Another downside of using the smb://user:password link is that it displays the username in the address bar. This means that when I need to quickly share a full folder path with a colleague, I have to manually edit it to remove the username.

While it is still functional, the decision to remove the default fallback login from the settings has made my experience with Plasma significantly more difficult.

Luckily I do not have to deal with proxies.

If there’s anything I can do to help bring attention to this issue, I would be more than willing to assist.

edit: Here the mentioned bug removed default credential feature in Plasma 5, which was for me working perfect.
164283

PS: Why cant the community not link to the KDE own bugs page?

The issue of entering SMB access credentials over and over again is just a nuisance that can be overlooked. However the problem of it assigning different local routes every time an SMB route is mounted on the fly is a productivity issue.

But leaving aside the problem with SMB routes, I did take the trouble again to create two different threads related to the use of proxies in intranets. One of the problems is recent 491711 – Plasma ignores proxy settings on FTP accesses (it used to work) and the other has NEVER worked (although I had reported it before) 491715 – Plasma does not prompt for username and password when using a proxy with authentication.

2 Likes