Very weird SMB behavior from Windows 10

[maxx`]

Hey folks,

I am going through a very weird behavior with one share opened in Windows 10.

I can write to my share without any issues and speed is maxing out my Gigabit connection, no issues here. I can go through folders, open and read files..

.. except if I'm trying to open an image file (.jpg) using the default Photos app (double-click), the image opens but get truncated in the middle. As a result I see only a portion of the image, truncated in half.
I have the exact same behavior for every pictures, not matter the folder. Explorer ends up frozen if I try to open too much images consecutively.

If I open the Properties of those files, it is very slow to appear, perfectly normal on others.

Permissions look correct.

If I open a .pdf file, I have no issue, the file correctly opens in Adobe Acrobat Reader.

If I try to open the same image in Adobe Photoshop Express, I have no issue.

If I connect to the same share using my macbook, I can open everything without any issues.

Visual example of the image opened in Photos:

http://imgur.com/a/PgTUZ

If I look at samba logs, here is what I see:

Code:

  maxx opened file folderXXX/imageXXX.jpg read=No write=No (numopen=8)
[2016/12/19 19:40:12.881852,  2] ../source3/smbd/close.c:790(close_normal_file)
  maxx closed file folderXXX/imageXXX.jpg (numopen=7) NT_STATUS_OK
[2016/12/19 19:40:13.195625,  2] ../source3/smbd/open.c:1005(open_file)
  maxx opened file folderXXX/imageXXX.jpg read=Yes write=No (numopen=8)
[2016/12/19 19:40:13.269025,  2] ../source3/smbd/open.c:1005(open_file)
  maxx opened file folderXXX/imageXXX.jpg read=Yes write=No (numopen=10)
[2016/12/19 19:40:13.269646,  2] ../source3/smbd/open.c:1005(open_file)
  maxx opened file folderXXX/imageXXX.jpg read=Yes write=No (numopen=10)
[2016/12/19 19:40:13.282769,  2] ../source3/smbd/close.c:790(close_normal_file)
  maxx closed file folderXXX/imageXXX.jpg (numopen=9) NT_STATUS_OK
[2016/12/19 19:40:18.161180,  2] ../source3/smbd/close.c:790(close_normal_file)
  maxx closed file folderXXX/desktop.ini (numopen=9) NT_STATUS_OK

As you can see, there are lots of open and close for the exact same file.

I thought of a lock issue so I tried to set oplock off in the samba conf, but it's not working better.

I tried to google this issue, which I'm sure will end up a simple, but without success..

Any ideas someone?

 

[anodos]

You're going to have to provide more information:

• Client details
• Server details (version of freenas, full hardware details, etc)
• Network details (wireless, wired, VPN, switch, etc.)
• Samba details (contents of /var/log/samba4/log.smbd, /usr/local/etc/smb4.conf, output of "smbstatus" when connected, etc)
• Permissions details (output of "getfacl /mnt/<pool>/<dataset>/file.jpg")

The above would be a good start to give an idea about what is going wrong. For the record, the photos app does not appear to be having problems on my computer.

A few client-side things to check:

• Verify that your computer isn't configured to turn off the NIC to save power. To do this, open "Device Manager" as an admin user, expand "Network adapters", right-click on your NIC and click properties. If there is a "Power Management" tab, click on it and uncheck the box "Allow the computer to turn off this device to save power".
• Try connecting by IP-address rather than netbios name. i.e. "\\192.168.0.10\share"

 

[Ericloewe]

For the record, the photos app does not appear to be having problems on my computer.

Works fine for me, too. Works with the NetBIOS name, too.

 

[maxx`]

- Client details: Windows 10 Enterprise
- Server details (version of freenas, full hardware details, etc): FreeNAS-9.10.1-U4, updated
- Network details (wireless, wired, VPN, switch, etc.): LAN, wired, 1000Mb
- Samba details (contents of /var/log/samba4/log.smbd, /usr/local/etc/smb4.conf, output of "smbstatus" when connected, etc):
smb4.conf:

Code:

[global]
	server min protocol = SMB2
	server max protocol = SMB3_11
	encrypt passwords = yes
	dns proxy = no
	strict locking = no
	oplocks = yes
	deadtime = 15
	max log size = 51200
	max open files = 937730
	logging = file
	load printers = no
	printing = bsd
	printcap name = /dev/null
	disable spoolss = yes
	getwd cache = yes
	guest account = nobody
	map to guest = Bad User
	obey pam restrictions = yes
	directory name cache size = 0
	kernel change notify = no
	panic action = /usr/local/libexec/samba/samba-backtrace
	nsupdate command = /usr/local/bin/samba-nsupdate -g
	server string = FreeNAS Server
	ea support = yes
	store dos attributes = yes
	lm announce = yes
	time server = yes
	acl allow execute always = true
	dos filemode = yes
	multicast dns register = yes
	domain logons = no
	local master = yes
	idmap config *: backend = tdb
	idmap config *: range = 90000001-100000000
	server role = standalone
	netbios name = FREENAS
	workgroup = WORKGROUP
	security = user
	pid directory = /var/run/samba
	create mask = 0666
	directory mask = 0777
	client ntlmv2 auth = yes
	dos charset = CP437
	unix charset = UTF-8
	log level = 2
	socket options = TCP_NODELAY SO_RCVBUF=131072 SO_SNDBUF=131072
	large readwrite = yes
	use sendfile = true
	write cache size = 1024000
	oplocks = yes


[zData]
	path = /mnt/zData
	printable = no
	veto files = /.snapshot/.windows/.mac/.zfs/
	writeable = yes
	browseable = yes
	vfs objects = zfs_space zfsacl aio_pthread
	hide dot files = yes
	guest ok = no
	nfs4:mode = special
	nfs4:acedup = merge
	nfs4:chown = true
	zfsacl:acesort = dontcare

- Permissions details (output of "getfacl /mnt/<pool>/<dataset>/file.jpg"):

Code:

# file: folderXXX/imageXXX.jpg
# owner: maxx
# group: users
			owner@:rwxpDdaARWcCos:-------:allow
			group@:rwxpDdaARWcCos:-------:allow
		 everyone@:r-x---a-R-c---:-------:allow

 

[maxx`]

A few client-side things to check:

• Verify that your computer isn't configured to turn off the NIC to save power. To do this, open "Device Manager" as an admin user, expand "Network adapters", right-click on your NIC and click properties. If there is a "Power Management" tab, click on it and uncheck the box "Allow the computer to turn off this device to save power".
• Try connecting by IP-address rather than netbios name. i.e. "\\192.168.0.10\share"

I just removed the power management for the NIC (nice hint, I usually do it), also it doesn't change anything.

I'm already using IP address directly.

 

[maxx`]

Works fine for me, too. Works with the NetBIOS name, too.

Yea, I really don't think it is a Photos Windows app issue, but much more something some other app are not sensible of.

I've just tried with a video file (.mkv) with vlc and it's doing the same: the file opens, the video starts and then it hangs.

 

[m0nkey_]

Help's to understand the full story.

• Server details (version of freenas, full hardware details, etc)

• Network details (wireless, wired, VPN, switch, etc.)

Please provide hardware details as requested by @anodos.

 

[maxx`]

Hardware:

• Supermicro X11SSM-F
• Intel Core i3-6100
• 32GB Kingston RAM ECC
• Seasonic Platinum P-760 power supply
• 6 Hard drives in raidz2
• 16GB sandisk usb key for the system

 

[anodos]

Code:

[global]
	socket options = TCP_NODELAY SO_RCVBUF=131072 SO_SNDBUF=131072
	large readwrite = yes
	use sendfile = true
	write cache size = 1024000
	oplocks = yes

Remove ALL auxiliary parameters from "services" -> "SMB" and retest. Mucking around

How are drives connected to the server? Directly to motherboard?

 

[maxx`]

That's it! You nailed it! Thanks a lot ;)

Removing the auxiliary parameters from samba is solving the issue.

Unfortunately it's also halving my transfer speed..

I'm now re-applying each setting one by one to identify the faulty one.

 

[maxx`]

Code:

use sendfile = true

is the bad one.

I don't know why, I thought sendfile was supported on FreeBSD.

 

[anodos]

Code:

use sendfile = true

is the bad one.

I don't know why, I thought sendfile was supported on freebsd.

I haven't looked into it. These aren't magical "go fast" parameters. In fact, some prominent members of the Samba mailing list refer to them (particularly "socket options") as voodoo that they have to keep around for compatibility reasons.

I've read that "use sendfile = yes" is incompatible with aio and so that might be an issue, but it is possible that it doesn't work on FreeBSD. That said, I don't really see any reason why one would need to enable it (despite the cut-and-paste consensus in the blog-o-sphere regarding samba 'tuning').

If you're trying to optimize performance for directories containing lots of files, there is a much better optimization route that JRA / the samba team recommends:
1) create your dataset with case sensitivity set to "insensitive".
2) set the auxiliary parameter "case sensitive = true".

This eliminates the need for Samba to perform case sensitivity checks and can dramatically improve performance on shares containing lots of files.

By the way, TCP_NODELAY,, large readwrite = yes, and oplocks = yes are defaults in Samba. Adding them to your auxiliary parameters is totally redundant.