Jump to content

_whatever

Members
  • Posts

    31
  • Joined

Everything posted by _whatever

  1. I see a lot of "STATUS_OBJECT_NAME_NOT_FOUND" in response to trying to create files, and the client then sending successive create requests. I'm not extremely well versed in Wireshark or SMB, but, this definitely looks odd. Can you share your samba config? I'm curious to see what /etc/smb.con and /boot/config/smb-extra.conf have in them on your server.
  2. Can you re-run the capture but this time write the .cap file to a temp folder (i.e. /root) that isn't a share and reproduce the issue? Then copy the file off after you stop the capture. This has a lot of extraneous stuff in it that I can't filter very easily. I'll take a closer look at it later this evening.
  3. If you install the Nerd Pack plugin you can install tcpdump. From there you can collect a packet capture at the server by going to the command line and running something like 'tcpdump -w /mnt/user/pub/tcpdump.cap -i br0'. You will need to change the path to whatever folder you want it in, pub just happens to be a share I have setup. You may also need to change your interface name, though it should be br0. Hit enter and it will start the capture, then start copying the files to reproduce the slowness. After maybe 60 seconds or so you can hit CTRL-C to stop the capture. You can open the file in Wireshark, or, if you're comfortable, you can zip it up and share it here for review. Alternatively you can do all of this from the client side using Wireshark as well, though, it may require a packet capture from both to more effectively see what is happening. I'd personally start with the capture at the server as I think this will provide the most valuable data. This article looks like it has some pretty good info regarding using Wireshark to capture SMB. https://thebackroomtech.com/2019/05/22/using-wireshark-to-sniff-an-smb-transmission/
  4. Yeah, that's a pretty big disparity. Are you using a *nix OS on the client, or is it a Windows machine? What kind of NIC is in your server? I'd be curious to see what a packet capture shows if you reproduce the slowness. I will try to reproduce some results in my lab to see if I can recreate the issue as well. Just food for thought, I'd be sure your Samba config isn't forcing use of SMB1. Years ago we had an issue at work where users would complain of super long logon times in the legacy Server 2003 farm we were migrating off of. Turned out that a bunch of crap had been roamed in their profiles; thousands of tiny files. Because Server 2003 only supported SMB1, and even though the SAN was very capable, the servers could only copy the files sequentially and the result was instead of a 30 second logon time, users were seeing hours long logon times in some cases.
  5. Slow transfer of small files over SMB is expected behavior if there are a lot of small files, whether that be Microsoft SMB or *nix and Samba. But if you're seeing a large disparity between a Windows share and an Unraid share when copying the same files, that definitely indicates a problem. Though I'd be curious what the disparity is between the two if you copy a single large file for testing. In the past I had seen similar slowness using Samba on *nix machines and the usual fix was to modify the Samba config to enable the socket option "TCP_NODELAY". I have not tried this myself on Unraid as I have not seen slow throughput over SMB, though I typically do large image backups and don't copy a large number of small files. I see close to a full gigabit (the client NIC speed) across my network when doing image backups using Macrium Reflect to an SMB share I have on my Unraid server. https://www.samba.org/~ab/output/htmldocs/Samba3-HOWTO/speed.html
×
×
  • Create New...