I have setup a system to work as a NAS drive using Debian on standard amd64 hardware using a usb harddrive with a fat32 partition as the media. I cannot copy big files onto this share. Explorer (WinXP) appears to hang for ~1 minute and then reports TITLE: "Error Copying File or Folder" MESSAGE: "Cannot copy <filename>: The specified network name is no longer available." > uname -a Linux 2.6.26-2-amd64 #1 SMP Thu Nov 5 02:23:12 UTC 2009 x86_64 GNU/Linux > smbstatus Samba version 3.4.3-SerNet-Debian
Please upload a strace of the smbd process. I suspect that a syscall takes too long. To take that strace, please connect to the NAS box, look with smbstatus which process is responsible for your client, and then issue a strace -ttT -o /tmp/smbd.trace -p <smbd-pid> where "<smbd-pid>" is replaced with the numeric process id you found with smbstatus. Probably the last couple of hundred lines of the file /tmp/smbd.strace are sufficient. In a next step, we might ask you for a debug level 10 log, but in this first run, the strace will probably be most interesting. Volker
Created attachment 5067 [details] Trace Trace made with strace
Last line of the trace is: 20:19:55.674192 ftruncate(28, 344209408 <unfinished ...> It looks like ftruncate may be the problem. I have seen some old posts about ftruncate on vfat. http://lists.samba.org/archive/samba/2003-April/065262.html I don't know if they are relevant?
vfat does not support sparse files, afaik the kernel HAS to will up the file with zeroes it it's ftuncated to a given size. If the drive IO is slow this takes a ling time. I guess fallocate in the kernel vfs filesystem driver will never come. This problem is probably unfixable. Mounting with async option or a much more aggressive fs caching of the drive might be a workaround in your case.
Oh, this is not fixable? At least responding to the SMBecho requests when putting the ftruncate call into an async thread should give us a lot more time. Or do you have a different experience? Volker
Ok, but is there nothing samba can do to still keep the connection with the client computer. I can copy the files fine to a windows "server" sharing the same drive even if it is slow. A slow drive/IO is hardly a reason to just stop talking to the client over the network. But then, the client might not be very well written and expect the ftruncate to be instant.
Security is not anything I'm interested in for this drive, so overwriting with zeroes to erase the data is not necessary. Maybe a flag to vfat when mounting to disable the zeroing could be a solution. I realise that this is not the right place for that suggestion. But do you have any comments?
I am very sorry to say that, but there is no quick fix for this. I am sure that this will come within the next months, but it is no quick solution possible except to write a VFS module that ignores that VFS call. This gives up a little bit of protocol correctness, but it will help your problem. Would you be in the position to test such a VFS module? Volker
Yes, sure. I assume that what the windows client is looking to do is to allocate the space for the file rather than fill it with zeroes. Is there another call (other than ftruncate) to the fs in linux that can do that?
Currently, I am also faced with this problem. It is exactly the same state. Server OS : CentOS 6.2 64bit Samba Version : 3.6.17 (and tried 3.6.5, 4.0.9) Use the 16GB USB MemoryStick, and allocating a shared folder in samba This problem, Is there a chance of being fixed in future versions? I'm sorry. Because I am not used to English, a text may be strange.
Any update on this issue ? I tried samba 4.7.x, still the same issue
don't use FAT/VFAT, exFAT has a chance to be a better choice for USB harddrives (if the kernel driver improves), see https://lists.samba.org/archive/samba-technical/2020-December/136068.html