I have a home share with a directory containing symbolic links to several disks (mount points, e.g. /home/<user>/links/disk1, etc.). Without or with a dfree command the actual disk free is correct for my home directory and the disks with windows explorer (dir). However when I copy a huge directory into a linked disk I get a complaint that the free size is not enough, as it takes the free space from the home directory. To overcome this problem I always used a dfree command which returned fixed values (loosing the real disk free with dir commands when directory is on another disk): echo 10000000000 10000000000 Is this a bug within Samba or a limitation of the SMB/CIFS protocol that it chooses to retrieve the disk free of the root directory of the share?
Can you post wireshark traces of the client activity before reporting the "not enough space" error please ? Not sure this is really a bug yet.
Created attachment 17653 [details] Wireshark capture
Created attachment 17654 [details] Wireshark capture
I noticed that the problem does not exist when copying from the command line. Also, copying to the share (on the home FS) starts and fails after the disk is full, so no space check is made upfront. The problem occurs with Windows Explorer (also with FreeCommander), both show the same message, so it seems to be Windows internal. Opened Windows Explorer (1) C:\temp Windows Explorer (2) X:\links\store\store6\backup\OnLinkedDisk On Linux: tshark -p -w samba_tshark_15239_002.pcap -i eno1 -f "port 445 and host 10.1.1.13" Copied bigfile.txt from (1) to (2): samba_tshark_15239_copy_fails.pcap I noticed that the FileFsFullSizeInformation uses a file-id from a "Create Request File" with an empty filename. As a second test I used FreeCommander with to open tabs to the above two folders and switched slowly between the tabs: samba_tshark_15239_switching_tabs.pcap Here a file-id is used from a "Create Request File" with the foldername as the filename. The returned FS info is correct.
Opening a name of "" is opening a handle on the root of the share. In both wireshark traces similar amounts of free space is being returned. 11722016 in the first trace, 11722000 in the second. Less free space is being returned in the second trace, so I'm confused as to which trace works here.
First trace (copy to links\store\store6\backup\OnLinkedDisk): In request #5 there is no filename provided. Response #6 returns the low FS-info of the home share: 11GB. It should have asked for the FS-info of the folder links\store\store6\backup\OnLinkedDisk to receive the correct information. #9 and #11 are requests with a file-id which is not captured, the responses #10 and #12 are also 11GB. The second trace (tabbing between the folders) returns the responses of FS-info, which are correct: links\store\store6\backup\OnLinkedDisk #17 #56: 1.1TB tmp\OnHomeShare #38 #77: 11GB
(In reply to fr.herbers from comment #6) > First trace (copy to links\store\store6\backup\OnLinkedDisk): > In request #5 there is no filename provided. > Response #6 returns the low FS-info of the home share: 11GB. Yes, that's what the client asked for. > It should have asked for the FS-info of the folder > links\store\store6\backup\OnLinkedDisk to receive the correct information. Hang on a minute, are you crossing mount points within the share ? That's explicitly confusing - don't do that. I'm not sure, but I think the Windows client assumes that everything below a share is on the same filesystem, therefore the free space from the root of the share is good for any path on the filesystem.
>>>I have a home share with a directory containing symbolic links to several disks (mount points, e.g. /home/<user>/links/disk1, etc.).
So I think you'll have to use a custom "dfree command" parameter that sums the space available. This isn't a bug, there's simply no way for a client to know that the share is patched up into different filesystems unless you use DFS redirects.
Well I don't need to have the space summed up. I have several disks mounted on /store/diskX and in my home directory I have a link to this /store. I created the following dfree script. if [ "$1" = '.' ] then echo 10000000000 10000000000 else /bin/df $1 | tail -1 | awk '{print $2" "$4}' fi In case of a disk free of the share and before a file is copied with Windows Explorer Samba calls the script with "." All other folders call the script with the folder path. So I have a wrong disk free for the home share root folder (but I can live with that). All other disk free from a subdirectory within the share and also for the linked disk/subdirectories are correct. Before a copy of a big file the disk free returns the max disk free and copying works now. This fixed by issue.