I have a SQL backup plan that writes the backups to a SAMBA network share. I have a T-SQL net use (with persistent:yes) script that is the first part of the maintenance plan to access the share. This worked for a while but now it is failing now on my larger databases. Samba just says "write_data: write failure in writing to client Error Broken pipe" in the log. In SQL Server, I just get Operating system error 64(The specified network name is no longer available').

If I backup just the big database manually with "Tasks" in SQL Server, it works.

  • When this happens, is smdb soaking up 100% cpu on 'top'? Is this an encrypted backup? Oct 26 '10 at 15:28

Typically that error is a sign that the remote SMB server disappeared.

I wonder if you're seeing this bug. It doesn't look like it's been tracked-down to root cause yet.

Does the failure occur at the same position in the backup data stream each time? (You mentioned that it's "big"-- I'm wondering you're overflowing a 32-bit counter somewhere.) How big are you talking about (if you'd prefer not to give out the size, give us an order of magnitude).


I think you'll need some more extensive logging on the smbd side, and probably a sniff of the network traffic, to get anywhere with this.

I'm seeing somebody on the Samba list chasing the same problem and getting nowhere (primarily because the people on the list are trying to get him to chase wild geese, by the look of it).

  • Nothing in the daemon log. The file is around 20GByte, but like I said, if I do that file by itself it is fine. Oct 26 '10 at 14:51
  • What version of Samba are you on? Oct 26 '10 at 15:04
  • The version is 3.4.7 Oct 26 '10 at 15:05

This guy had the same problem about the broken pipe; http://blog.binarystars.com/2007/08/25/samba-error-writing-75-bytes-to-client-1-broken-pipe/

He found out that the windows server was creating a network loop, because both NICs were plugged into the network. He had to block one of the IPs in IPtables to resolve the issue.


I have seen this happen when the SQL Agent service running user itself does not have the rights to write to the samba share and as a result it would error out. A good way to determine if that is the case is try manually running the backup.

  • The manual back works (Mentioned that in the last part of the question). Also, most of the databases work, it just dies out on the larger one and then continues on to the rest of the smaller ones. Oct 26 '10 at 14:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.