Cannot copy ... : The specified network name is not longer available

[Joe L.]

I tried again with debug level on smbd set to 10.

No further detail was given.

as before, he last two debug lines preceding the crash were:
read_data: read failure for 4 bytes to client 192.168.2.6. Error = Connection reset by peer
timeout_processing: receive_smb error (Connection reset by peer) Exiting

It happens whenever I try to play a movie stored on the unRaid server WHILE I am using bittorrent to download files TO a /mnt/disk3/data folder on the unRaid server from the same PC.   I was not reading, nor writing to the user-shares at the time the error occurred.   

It is repeatable if reading/playing a movie and writing from bittorrent from the SAME PC.  Within a few minutes of starting the movie, the errors occur.

So far, it does not seem to occur when I am playing a movie on one of my MG-35 lan-based media players from a file on the unRaid array, even though I am writing to to it from the PC from a running bittorrent.

Joe L.



Joe L.

[limetech]

Trying to reproduce this - so far have not, though I have not tried writing with any bittorrent program.

Joe, can you try again, this time reading movie direct from a disk share, not a user share, if possible?

[Joe L.]

Tom,

I was not using any "User Share" at all in my tests.  Sorry if I did not make that more clear in my previous post.

I was downloading a bittorrent using Azureus as the client to \\tower\disk3\data\new folder(3)\file...
I was playing a different movie file from \\tower\disk3\data\new folder(3)\other_file

My disk shares are read/write, but hidden. I have to type the path to get to the files, they do not show in windows explorer

So... I do not think the user-shares have anything to do with it.

The bittorrent's can run for hours unless I try to play a movie using the same PC.  Then the connection breaks, apparently with some kind of timeout.

Joe L.

[rhinoman]

I'm not using user shares either, just standard writes to a disk share.

[Tybio]

I've run into this as well, thought I chalked it up to being a beta release.  I was using user-shares however, but had similar results, the main difference was that I was seeding the torrents so the client was only reading data...any other activity on the disk that lasted more then a few seconds would cause the torrents to error out seeding until I rechecked them.

[wanton]

This happened me yesterday when i was copying 40GB to user share. I'm running 4.2 beta 3 with P5B-VM DO, Intel Core 2 Duo E4400, 2x 512MB kingston 533mhz ddr2. I have 4 500GB drives + 1 500GB parity drive. No memory errors. Tested with memtest 86+ and windiag with multiple passes.
It had copied around 30GB over and was copying one allmost 2GB file and after that file i got this error. I was moving files to user share.

Odd thing is that this little less than 2GB file was copied but wasn't delete from my machine that i was moving this file from.
Sadly i didn't check if that file was ok on unraid server but overwrote it in my stupidity.
Share i'm moving files to was like //tower/myusershare. So it wasn't mapped drive if that has anything to do with it.

Since i have Core 2 Duo so it should do multiprocessing maybe this is might some dual processor problem? Maybe code isn't thread safe?

Let me know how can i check my logs to see if there is something there.

Also i might have been seeding some files of unRaid with bittorrent during this error or not. I have couple of files in my seeding que that are on unRaid server so depending if they where started or not during that copy.

[NAS]

thought it might be worth mentioning that i never torrent to unRAID and i still see this error

[Joe L.]

thought it might be worth mentioning that i never torrent to unRAID and i still see this error

I think the error has something to do with simultaneous reading and writing.   Bittorrent happens to do a lot of that, so it will encounter the error more frequently than other programs.

Yesterday, I saw the network disconnect error occur when the bittorrent program was NOT in use.

Joe L.

[rhinoman]

I was seeing this error with 4.2.4b but having gone back to 4.1 it has disappeared. I too was only writing, not streaming at the same time.

[Joe L.]

I was seeing this error with 4.2.4b but having gone back to 4.1 it has disappeared. I too was only writing, not streaming at the same time.

Yes, but even when "*we*" think we are only writing, windows itself is often doing "reads" to keep itself in sync for folder listings, etc.

I don't think I ever saw it in 4.1 either.   Probably should try older version of smbd and see if problem goes away. (It could be samba, it could be the networking itself, it  could be in the OS.  Need to start isolating the cause one thing at a time)

Joe L.

[wanton]

I think problem we are having is this exact problem in samba mailing lists. http://lists.samba.org/archive/samba/2007-July/133789.html seems that it's problem with samba 3.0.25b

Bugzilla is here https://bugzilla.samba.org/show_bug.cgi?id=4796

[Joe L.]

The official bug report...  made to the samba developers is here:
https://bugzilla.samba.org/show_bug.cgi?id=4796

and their patch to fix the problem is here:
https://bugzilla.samba.org/attachment.cgi?id=2827

Tom... looks like you might just have an answer for your next release.

Joe L.

[Tybio]

Can't wait for a beta with this patch on it, having to do some serious planning to get data onto the unRAID box when it will not error out

[Joe L.]

I was seeing this error with 4.2.4b but having gone back to 4.1 it has disappeared. I too was only writing, not streaming at the same time.

Yes, but even when "*we*" think we are only writing, windows itself is often doing "reads" to keep itself in sync for folder listings, etc.

I don't think I ever saw it in 4.1 either.   Probably should try older version of smbd and see if problem goes away. (It could be samba, it could be the networking itself, it  could be in the OS.  Need to start isolating the cause one thing at a time)

Joe L.

The version of smbd that has the disconnect bug is 3.0.25b

To tell if you have the buggy version, login via telnet and type:
/usr/sbin/smbd -V

The working version is 3.0.24.
I sure the buggy version of smbd is in unRaid 4.2 and think it might even be in 4.1. Edit: unRaid 4.1 uses version 3.0.24 of smbd.

I've now got a copy of smbd 3.0.24 on my flash drive.  I've also added a line to my "go" script to copy
it to /usr/sbin/smbd just prior to emhttp being invoked.
This will fix the disconnect bug for me until Tom can get a newer version in a new release of unRaid.

cp /boot/smbd /usr/sbin/smbd; chmod +x /usr/sbin/smbd

Joe L.
PS.
easiest way to get the older version is to boot up an older release of unRaid and then copy the file to the flash drive.
cp /usr/sbin/smbd /boot/smbd
Then, boot up the newer release and the file should be there for your use.  I got my older (version) copy of smbd from unRaid 4.0beta9 since I had it on my alternate flash drive.

[wanton]

That doesn't work. But thanks for the idea Here is edited version.

I'm running 4.2 beta 3 here is what I did.

To use \\tower\flash share you need to enable it from the web interface first.

Copied bzimage, bzboot and syslinux.cfg from 4.1 zip to flash share and rebooted. When 4.1 was running did "cp /usr/sbin/smbd /boot" from commandline

Then edited go file on flash share to look like this

#!/bin/bash

# Shutdown Samba then copy samba 3.0.24 to sbin and start samba
killall smbd nmbd
sleep 2
cp /boot/smbd /usr/sbin/smbd
chmod +x /usr/sbin/smbd
/etc/rc.d/rc.samba

# Start the Management Utility
/usr/local/sbin/emhttp &

Then copied bzimage, bzboot and syslinux.cfg from 4.2 beta3 zip to flash share and rebooted.

That's it.