Strange Samba/CIFS issue: can rename, delete, play video, but can't copy

[chiem]

Fairly new to FreeNAS (v9.2.1.8) and this was working fine a few days ago, but now I'm running into this weird issue. The only changes I can think of are enabling some plugins (plex, transmission).

In one specific example, I have a video in a Samba/CIFS share. I can rename that file. I can delete it. I can play it with something like VLC. However, I can't copy the file over to my Win7 box. I can even move a file from my Win7 box to the share, but can't move it back. It's usually instant, but sometimes it'll run for a few secs before popping up a window that saids:

"There is a problem accessing \\NAS\Share

Make sure you are connected to the network and try again."

When this happens, syslog on FreeNAS shows:

Nov 12 12:37:44 nas smbd[9449]: [2014/11/12 12:37:44.439336, 0] ../source3/smbd/smb2_read.c:273(smb2_sendfile_send_data)
Nov 12 12:37:44 nas smbd[9449]: smb2_sendfile_send_data: fake_sendfile failed for file video.mkv (Socket is not connected). Terminating
Nov 12 12:37:44 nas kernel: pid 9449 (smbd), uid 0: exited on signal 11 (core dumped)

I can copy the video without problems on my MBP mounting the smb share, so this seems to be a problem on the Windows side, but I've rebooted the Windows box and it still happens. Anyone else run into this before ?

 

[chiem]

Looks like the problem is due to this line in my smb4.conf:

"use sendfile = true"

I could have sworn it worked fine a few days ago with that, and I've been using that option in Samba for years.

Can anyone shed some light on why that option is suddenly preventing me from copying files off the NAS ?

 

[anodos]

Looks like the problem is due to this line in my smb4.conf:

"use sendfile = true"

I could have sworn it worked fine a few days ago with that, and I've been using that option in Samba for years.

Can anyone shed some light on why that option is suddenly preventing me from copying files off the NAS ?

It's probably a code change in Samba. SMB2 is significantly different than SMB1, it may be that setting "use sendfile=true" causes samba to barf on itself during SMB2 connections that aren't operating server-side. You could see if dropping server max protocol to NT1 "fixes" the problem. If it does, then I would keep the max protocol at SMB3 (or whatever the default is) and just not set the "use sendfile" parameter. The problem wouldn't have manifested itself under an XP or smbclient connection because those won't go above NT1. Depending on the version of OSX, you may be connecting via SMB1. (Default until fairly recently)

If you are feeling particularly ambitious, try getting a level 10 diagnostic of the problem and posting on the samba mailing lists or making a bug report on samba's bugzilla. I think if you file a bug report with FreeNAS you will get a "well, don't set that parameter" response. :)

 

[Ericloewe]

It's probably a code change in Samba. SMB2 is significantly different than SMB1, it may be that setting "use sendfile=true" causes samba to barf on itself during SMB2 connections that aren't operating server-side. You could see if dropping server max protocol to NT1 "fixes" the problem. If it does, then I would keep the max protocol at SMB3 (or whatever the default is) and just not set the "use sendfile" parameter. The problem wouldn't have manifested itself under an XP or smbclient connection because those won't go above NT1. Depending on the version of OSX, you may be connecting via SMB1. (Default until fairly recently)

If you are feeling particularly ambitious, try getting a level 10 debug of the problem and posting on the samba mailing lists or making a bug report on samba's bugzilla. I think if you file a bug report with FreeNAS you will get a "well, don't set that parameter" response. :)

Level 10 debug? Like a "level 10 diagnostic"? Since when did Samba start using Star Trek terminology?

Come to think of it, it makes sense. They pull technobabble out of their asses and it magically turns into a usable SMB stack.

 

[anodos]

Level 10 debug? Like a "level 10 diagnostic"? Since when did Samba start using Star Trek terminology?

Come to think of it, it makes sense. They pull technobabble out of their asses and it magically turns into a usable SMB stack.

My post has been corrected to properly reflect star trek terminology. Don't even get me started on the jefferies tube. There are some times when reversing the polarity of nmbd can resolve problems with netbios name resolution.

 

[cyberjock]

What!? You guys have it all wrong. Use a tacheon pulse to detect the wake from an impulse engine of the cloaked ship! Duh!

Freakin' noobs. ;)

As for the sendfile, it's something that shouldn't normally have any downside, so it's enabled by default. The fact that your windows 7 box is having a problem with it makes me think that either your FreeNAS install is somehow messed up or your Windows 7 install has some custom CIFS tuning parameters set in the registry causing that behavior. That's definitely not the norm and something is definitely wrong.

 

[chiem]

As for the sendfile, it's something that shouldn't normally have any downside, so it's enabled by default. The fact that your windows 7 box is having a problem with it makes me think that either your FreeNAS install is somehow messed up or your Windows 7 install has some custom CIFS tuning parameters set in the registry causing that behavior. That's definitely not the norm and something is definitely wrong.

It's not enabled by default.

 

[anodos]

As for the sendfile, it's something that shouldn't normally have any downside, so it's enabled by default. The fact that your windows 7 box is having a problem with it makes me think that either your FreeNAS install is somehow messed up or your Windows 7 install has some custom CIFS tuning parameters set in the registry causing that behavior. That's definitely not the norm and something is definitely wrong.

the smb.conf manpage says;

use sendfile (S)
If this parameter is yes, and the sendfile() system call is supported by the underlying operating system, then some SMB read calls (mainly ReadAndX and ReadRaw) will use the more efficient sendfile system call for files that are exclusively oplocked. This may make more efficient use of the system CPU's and cause Samba to be faster. Samba automatically turns this off for clients that use protocol levels lower than NT LM 0.12 and when it detects a client is Windows 9x (using sendfile from Linux will cause these clients to fail).

Default: use sendfile = false

So it is not enabled by default.

Following FreeBSD mailing list entry indicates that "use sendfile" has been broken since 4.1.6: http://lists.freebsd.org/pipermail/freebsd-ports/2014-March/091162.html

 

[cyberjock]

I don't think you know what I mean. FreeNAS compiles the smb.conf file from defaults that the devs have chosen (along with your input from the WebGUI). The defaults that Samba uses do not necessarily reflect the defaults for FreeNAS.

That being said, I could have *sworn* that sendfile was made the default in FreeNAS 9.2.1.x, but that doesn't appear to be the case. Checking my 9.2.1.8 machine sendfile is not set, so the default setting in Samba (which is disabled) is used.

 

[anodos]

I don't think you know what I mean. FreeNAS compiles the smb.conf file from defaults that the devs have chosen (along with your input from the WebGUI). The defaults that Samba uses do not necessarily reflect the defaults for FreeNAS.

That being said, I could have *sworn* that sendfile was made the default in FreeNAS 9.2.1.x, but that doesn't appear to be the case. Checking my 9.2.1.8 machine sendfile is not set, so the default setting in Samba (which is disabled) is used.

Well, it appears you're not totally crazy :) https://github.com/freenas/freenas/commit/a83fe91900386c41e9bf6b84b7d72dab11f4ae2d

Probably was removed because sendfile support is apparently borken in SMB2

 

[cyberjock]

Wooho.. not totally crazy, just "mostly" now. :D

 

[chiem]

Following FreeBSD mailing list entry indicates that "use sendfile" has been broken since 4.1.6: http://lists.freebsd.org/pipermail/freebsd-ports/2014-March/091162.html

Not completely true. I have a linux box with smbd 4.1.7 where "use sendfile" works.

 

[anodos]

Not completely true. I have a linux box with smbd 4.1.7 where "use sendfile" works.

Well, even if you could get it to work it, most information I can find indicates that samba + ZFS + sendfile hurts performance rather than helping it (redundant caching).

Samba is a quickly moving target. Performance tuning that was necessary 4+ years ago under linux may hurt performance on a FreeNAS server. The defaults are usually good enough.

 

[chiem]

A little further digging shows that "use sendfile" uses the sendfile() system call, so it's OS specific, and perhaps filesystem specific as well.

sendfile(2) on a FreeBSD 10.0 box saids:

If a value of zero is reported for kern.ipc.nsfbufs, your architecture
does not need to use sendfile() buffers because their task can be effi-
ciently performed by the generic virtual memory structures.

And sysctl on the FreeNAS box shows:

$ sysctl kern.ipc.nsfbufs
kern.ipc.nsfbufs: 0

So I guess that option isn't needed anymore.

 

[chiem]

On a related note, I found this page:

http://www.en.sysadmin-cookbook.net/samba/

Which details an installation of Samba 3.6 on FreeBSD (unknown version) and notes that the "use sendfile" option causes breakage.

My previous NAS was a FreeBSD/zfs box that's been running Samba 3.6.x for years, under various versions of FreeBSD from 8.x to 10.0, and "use sendfile" works fine on it.

So.. /boggle.