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