Bug 431050

I've just tested this on Dolphin 20.12.0 and I can't replicate the issue. I have a full write access share on my server and this worked as expected with all steps.

Copying files on this share works with gvfs-based file managers.

(In reply to Peter Eszlari from comment #2)
> Copying files on this share works with gvfs-based file managers.

I'm wondering if being an older device that likely never got many firmware updates that the SMB version of it is causing issues.

Maybe gvfs-based file managers allow the older insecure smb versions.

This bug still exists in 5.24.6. All folders in shares report 0 B free. Gvfs based file managers work as expected.

SMB server is running Windows Server 2019. SMB v1 is disabled. SMB v2 and v3 are enabled. I will keep a laptop running Plasma if anyone wants to troubleshoot and need additional information provided. But this makes Plasma unusable in corporate Windows environments.

I also came across this bug

Dolphin: 21.12.3
Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 5.15.0-46-generic (64-bit)

Bug exits in Plasma 5.25.5 as well - test on Tumbleweed.

Still broken and reproducible in 5.26.4.

Same in KDE 5.24.7

Created attachment 155413 [details]
screenshot of error

Same here, cannot copy anything to my remote WDTV Livehub (Samba share). See error in attached screenshot. Creating a file does work.. so there it's not an inherent writing failure.

This bug seems related: https://bugs.kde.org/show_bug.cgi?id=462263

No write access with the same error displayed. I can delete stuff and create new folders but writing files is impossible. I use smb4k as a workaround but it opens a huge amount of files on our Windows Server shares (can be seen in the server logs) which are connected through DFS.

Dolphin: 22.12.2
Operating System: Fedora Linux 37 (KDE Spin)
KDE Plasma Version: 5.27.0
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.11-200.fc37.x86_64 (64-bit)
Graphics platform: Wayland

kio-extras has no role to play here. It simply tells the information from the server to the UI. It's dolphin's decision to enforce that limit ahead of writing. Moving bug to dolphin.

Interesting data points might be what dolphin reports as free space (Alt+Return in a folder) versus what the actual space reported on the server is.

(In reply to Harald Sitter from comment #13)
> Interesting data points might be what dolphin reports as free space
> (Alt+Return in a folder) versus what the actual space reported on the server
> is.

In the folder properties of my personal root directory (which is limited by a quota of 100 GB) for example Dolphin is reporting that "0 B of 0 B free" and that are 0 % are being used. A Windows 10 VM is reporting that the directory has a size of 70,1 GB. When I look at the disk space bar at the bottom right of the main window Dolphin shows 476,7 GiB as free. However I don't think that number is accurate. Last week a colleague at work said that smb clients only see the amount of space which is left on the system partition of the domain controller which hosts the particular smb share.

On shares without a per-user-quota the behavior is the same - 0 B of 0 B and 0 % used.

(In reply to fdkde from comment #14)
> (In reply to Harald Sitter from comment #13)
> > Interesting data points might be what dolphin reports as free space
> > (Alt+Return in a folder) versus what the actual space reported on the server
> > is.
> 
> In the folder properties of my personal root directory (which is limited by
> a quota of 100 GB) for example Dolphin is reporting that "0 B of 0 B free"
> and that are 0 % are being used. A Windows 10 VM is reporting that the
> directory has a size of 70,1 GB. When I look at the disk space bar at the
> bottom right of the main window Dolphin shows 476,7 GiB as free. However I
> don't think that number is accurate. Last week a colleague at work said that
> smb clients only see the amount of space which is left on the system
> partition of the domain controller which hosts the particular smb share.
> 
> On shares without a per-user-quota the behavior is the same - 0 B of 0 B and
> 0 % used.

Addition: The data itself is not located on the domain controllers. They only provide the smb shares to the clients.

Git commit 46d3f2fd41dece1d49e7295ae986d8e3960e78fb by Harald Sitter.
Committed on 21/02/2023 at 07:12.
Pushed by sitter into branch 'master'.

smb: don't tell the client if the available FS size is 0

it only triggers incorrect behavior in dolphin without any benefit
whatsoever

M  +7    -0    smb/kio_smb_browse.cpp

https://invent.kde.org/network/kio-extras/commit/46d3f2fd41dece1d49e7295ae986d8e3960e78fb

Git commit c2c799627aaf440b817fafa96f3662e78c629fe4 by Harald Sitter.
Committed on 21/02/2023 at 07:12.
Pushed by sitter into branch 'release/22.12'.

smb: don't tell the client if the available FS size is 0

it only triggers incorrect behavior in dolphin without any benefit
whatsoever
(cherry picked from commit 46d3f2fd41dece1d49e7295ae986d8e3960e78fb)

M  +7    -0    smb/kio_smb_browse.cpp

https://invent.kde.org/network/kio-extras/commit/c2c799627aaf440b817fafa96f3662e78c629fe4

Thanks for your patch. I tested a build of the kio-extras master branch on a Fedora VM. Dolphin does not not complain anymore about having insuffient space on the network share. Kudos to you 👍 👏 😊

However LibreOffice which uses the KDE file chooser window (through xdg-desktop-portal? I don't know) is throwing me an error, when I try to save a file directly on the smb share by entering the full path ("smb://user@domain.example/home/username..."): "Error saving the document Testdocument: Object not accessible. The object cannot be accessed due to insufficient user rights.". When the file is already existing on the smb share, changes are getting saved without error messages.

Mozilla Firefox (configured with widget.use-xdg-desktop-portal.mime-handler = 1 and widget.use-xdg-desktop-portal.file-picker =1 to use the KDE file picker through xdg-desktop-portal) doesn't show my personal network folder, only the folders above and no content on any smb-based folder. On some but not all smb shares I see an other error message which states that the file or folder I try to access doesn't exist.
Maybe I have those problems due to the fact that I tested your changes in a VM.

Maybe it's just the infrastructure of my enterprise network environment. I will test it on a normal system and report back if the issues still appear.

(In reply to fdkde from comment #18)
> Thanks for your patch. I tested a build of the kio-extras master branch on a
> Fedora VM. Dolphin does not not complain anymore about having insuffient
> space on the network share. Kudos to you 👍 👏 😊
> 
> However LibreOffice which uses the KDE file chooser window (through
> xdg-desktop-portal? I don't know) is throwing me an error, when I try to
> save a file directly on the smb share by entering the full path
> ("smb://user@domain.example/home/username..."): "Error saving the document
> Testdocument: Object not accessible. The object cannot be accessed due to
> insufficient user rights.". When the file is already existing on the smb
> share, changes are getting saved without error messages.
> 
> Mozilla Firefox (configured with widget.use-xdg-desktop-portal.mime-handler
> = 1 and widget.use-xdg-desktop-portal.file-picker =1 to use the KDE file
> picker through xdg-desktop-portal) doesn't show my personal network folder,
> only the folders above and no content on any smb-based folder. On some but
> not all smb shares I see an other error message which states that the file
> or folder I try to access doesn't exist.
> Maybe I have those problems due to the fact that I tested your changes in a
> VM.
> 
> Maybe it's just the infrastructure of my enterprise network environment. I
> will test it on a normal system and report back if the issues still appear.

EDIT: Sorry for the doubled negation. Dolphin does not complain anymore

I can confirm that this is working now correctly.

(tested with http://download.opensuse.org/repositories/KDE:/Medias/images/iso/openSUSE_Krypton.x86_64.iso)

This isn't fixed. Dolphin still behaves incorrectly. File system space is a hint, not necessarily reality. Just because the filesystem says there is no space doesn't mean there really isn't.

(In reply to Harald Sitter from comment #21)
> This isn't fixed. Dolphin still behaves incorrectly. File system space is a
> hint, not necessarily reality. Just because the filesystem says there is no
> space doesn't mean there really isn't.

Is there more data we could provide to debug this?

I hope that adds some more information which is helpful to track down the issue:

While browsing through some smb shares and folders with the modified kio-extras version I noticed some repeating error messages that Dolphin put out into the terminal session where I started it from:

session setup failed: NT_STATUS_NO_MEMORY
Unable to follow dfs referral [path to smb share]
Couldn't resolve [path to the accessed folder, starting from the smb share]

Info: I had to redact the smb share path and folders for confidential reasons.

Unfortunately I was too busy today to test if I get the same error messages on with my productive system without the modified kio-extras version. The problems I had on the VM are gone on a physical system but I got a new error message from LibreOffice when trying to write new files via smb:

Fehler beim Speichern des Dokuments Unbenannt 1:
Kein Zugriff auf Objekt.
Aufgrund fehlender Benutzerrechte kann auf das Objekt nicht zugegriffen werden.

Translated freely:

Error while saving the document Unbenannt 1:
No access on object.
It isn't possible to access the object due to missing user rights.

Saving existing file is working without problems. I don't know if the reason for that is our infrastructure or something that can be fixed by KDE or LibreOffice developers.
One thing I've noticed when trying the same with Kate is that the KDE file pickers for LibreOffice and Kate look quite similar. But there is one detail what catched my eye: The network/foreign devices section in the left pane of the file picker for LibreOffice is/was missing.
Two question for better understanding: How are the file pickers are getting created and configured? Can application developers decide if the KDE file picker is showing/supporting the network/foreign section or not?

*** Bug 469283 has been marked as a duplicate of this bug. ***

In case this is of any help (I cannot really follow the technical discussion here) : with 21.12.3, I am experiencing this problem when pasting files, but ``cp``ing them to the exact same location works.

For some time I was able to access the network shares via our fully qualified domain name. When I joined the machine with the domain by using sssd and realmd, the access to the DFS shares broke again. First I thought the domain join was the cause why it reappeared but on a fresh VM install with Fedora 39 I run into the same problem again:

session setup failed: NT_STATUS_NO_MEMORY
Unable to follow dfs referral [\filecluster\personal$]
Could not resolve \Personal\*
session setup failed: NT_STATUS_NO_MEMORY
Unable to follow dfs referral [\filecluster\personal$]
Could not resolve \Personal\

The only configuration changes I did to the VM:
- Put our domain as workgroup in /etc/samba/smb.conf
- Put the FQDN as search domain in the NetworkManager GUI for the Ethernet connection
- Changed the hostname in /etc/hostname including the actual domain name as the hostname of the VM defaulted to "fedora"

For some reason the VM can access the share via //filecluster (as proof see screenshot above) which is a (virtual) DNS name and a Active Directory object for our file server cluster. However KIO (still) complains about having not enough memory:

kf.kio.core: "Fehler. Nicht genügend Speicher.\nsmb://filecluster/personal$"

That doesn't work at all on my domain-joined host machine.

Dolphin: 23.08.1
Operating System: Fedora Linux 39 (KDE Spin)
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.111.0
Qt Version: 5.15.11
Kernel Version: 6.5.11-300.fc39.x86_64 (64-bit)
Graphics platform: Wayland

Created attachment 163110 [details]
NT_STATUS_NO_MEMORY when accessing DFS shares

Created attachment 163111 [details]
Accessing file clusters directly via SMB without DFS works

I think there are several failure modes with DFS, and they do not properly bubble up into kioworker or Dolphin:

1. If the DFS referal doesn't include the FQDN, this often results in slow operation or timeouts for Linux clients:

- Usually, smbclient will show "do_connect: Connection to srv-file-01 failed (Error NT_STATUS_NOT_FOUND)".
- Dolphin will show no error but present an empty folder.

FIX -> ask your admins to setup the DFS referals with the FQDN, otherwise there are multiple failure scenarios if connected via VPN, or slow DNS resolves because other local domains are queried first and may even resolve the IP. Always use FQDNs.

2. If you do not supply your logon domain with your user name, following the DFS referal will end in authentication errors because you did not get negotiate a session valid across the whole domain:

- Usually, smbclient will show "session setup failed: NT_STATUS_LOGON_FAILURE".
- Dolphin currently shows no error but presents an empty folder, I think it showed an auth error in an older version but leaving you clueless why it asked...

FIX -> Supply your logon domain with your username, e.g. "smbclient -U DOMAIN/user ...". If Dolphin asks, try "user@domain.local" instead.

3. I'm not sure why the last error occurs that some users reported:

- smbclient can show "session setup failed: NT_STATUS_NO_MEMORY".
- Again, Dolphin likely doesn't show the error but shows an empty folder instead.

GUESS -> I fixed both problems 1 and 2 here, smbclient works, Dolphin still fails (or kioworker?) - so maybe I got problem 3 now, or a whole different problem? kioworker doesn't log much. It seems to log only its own interpretation of the error situation which is obviously wrong, I only see variantes of the following:

Dez 28 17:16:08 jupiter kioworker[3216102]: Socket not connected QLocalSocket::PeerClosedError
Dez 28 17:16:08 jupiter kioworker[3216102]: An error occurred during write. The worker terminates now.

Dez 29 02:40:42 jupiter kioworker[30530]: Connection::send() called with connection not inited
Dez 29 02:40:42 jupiter kioworker[30530]: An error occurred during write. The worker terminates now.

These are the only two different messages logged by kioworker. Dolphin shows none of them but instead shows an empty folder.

I didn't even try to write a file at this point - because it's obviously wrong that the folder is empty.

That said, Dolphin seems to have very funny problems on its own with evaluating permissions or other properties. I have an NFS mount (not via kio) where Dolphin refuses to create folder or files directly in the mount point itself - it says "no permissions" or "not enough space". Creating files or folders via CLI shows no such problems. If I created a sub folder in the mount point, Dolphin no longer complains about it.

So whatever problems Dolphin shows, there are at least two possible sources: kioworker and Dolphin itself. Since kioworker doesn't log anything useful, and Dolphin doesn't seem to pass errors from kio properly to the user but "invents" its own (seemingly sometimes purely based on wild guessing of an observed situation), debugging the situation is almost impossible.

As mentioned in the comments it might be a DFS share problem. I have not tested it but in a lot of bug reports i see that mentioned

*** Bug 446244 has been marked as a duplicate of this bug. ***

*** Bug 429950 has been marked as a duplicate of this bug. ***

*** Bug 492108 has been marked as a duplicate of this bug. ***

(In reply to aristsakas from comment #32)
> *** Bug 429950 has been marked as a duplicate of this bug. ***

I don't think that this particular bug report is a duplicate...

1. It doesn't report 0 bytes free, it reports at least a tiny amount which may come from the fact that the wrong path is checked for free space, it doesn't seem to be about DFS, instead it's about remote directories where the remote side nests another mount inside.

2. The underlying problem is in fact rather that the system is becoming unusable when copying data with KIO, and the free space problem only became obvious after trying the work around with nested mounts.

This looks more like an instance of #450696

(In reply to Kai Krakow from comment #34)
> (In reply to aristsakas from comment #32)
> > *** Bug 429950 has been marked as a duplicate of this bug. ***
> 
> I don't think that this particular bug report is a duplicate...
> 
> 1. It doesn't report 0 bytes free, it reports at least a tiny amount which
> may come from the fact that the wrong path is checked for free space, it
> doesn't seem to be about DFS, instead it's about remote directories where
> the remote side nests another mount inside.
> 
> 2. The underlying problem is in fact rather that the system is becoming
> unusable when copying data with KIO, and the free space problem only became
> obvious after trying the work around with nested mounts.
> 
> This looks more like an instance of #450696

Thank you for the feedback. Sorry for the mistake