Crashing on Simultaneous Transfers


Recommended Posts

Possibly because it is deprecated, as its section title indicates:

Version 4.X Support (deprecated - use General Support above)

 

What version of unRAID are you currently running? 

 

Windows7 does have an issue with not closing files.  eventually unRAID would run out of open file descriptors.

 

There were several solutions posted, most all had to do with properly setting the ulimit (at the right time in the boot process)

 

Joe L.

 

Link to comment

unRAID ver. 4.7

 

I did try to set the limit in smb-extra.conf. My experience with that is it didn't help/work.

 

Here is what I tried. Set the limit in smb-extra.conf to:

[global]

max open files=40000

 

Rebooted the server. Checked the smb-extra.conf file and it was blank. Set it again, rebooted and it was blank again.

 

Configured smb-extra.conf but this time I used: smbcontrol smbd reload-config to reload the config. Tried Simultaneous Transfers and unRAID crashed.

 

I don't know why my smb-extra.conf is getting overwritten at boot. I think I read somewhere I could be because I'm running SNAP. I'm not sure how I would fix that though. But I wasn't too concerned about getting smb-extra.conf to stick if it didn't work anyhow.

 

Now I see you mentioned "(at the right time in the boot process)" and maybe that has something to so with it??? I did set the config before doing any file transfers.

 

As I mentioned on my last post in the previous thread, I would like to minimize how many times I have to crash me server as it is the one containing all my files.

 

The odd thing is, out of the 4 unRAID servers I've built this is only one with this issue, and its only an issue between this computer(my desktop) and the server. As pointed out before, I have tried simultaneous transfers to this server from 1 laptop running win7 x86, 1 laptop running win7 x64 and 1 desktop running win XP, all of them don't crash the server. My desktop running win7 x64 does, BUT only this server crashes. If I try simultaneous transfers on any of the other servers I have built they don't crash.

Link to comment

unRAID ver. 4.7

 

I did try to set the limit in smb-extra.conf. My experience with that is it didn't help/work.

 

Here is what I tried. Set the limit in smb-extra.conf to:

[global]

max open files=40000

 

Rebooted the server. Checked the smb-extra.conf file and it was blank. Set it again, rebooted and it was blank again.

 

Configured smb-extra.conf but this time I used: smbcontrol smbd reload-config to reload the config. Tried Simultaneous Transfers and unRAID crashed.

 

I don't know why my smb-extra.conf is getting overwritten at boot. I think I read somewhere I could be because I'm running SNAP. I'm not sure how I would fix that though. But I wasn't too concerned about getting smb-extra.conf to stick if it didn't work anyhow.

 

Now I see you mentioned "(at the right time in the boot process)" and maybe that has something to so with it??? I did set the config before doing any file transfers.

 

As I mentioned on my last post in the previous thread, I would like to minimize how many times I have to crash me server as it is the one containing all my files.

 

The odd thing is, out of the 4 unRAID servers I've built this is only one with this issue, and its only an issue between this computer(my desktop) and the server. As pointed out before, I have tried simultaneous transfers to this server from 1 laptop running win7 x86, 1 laptop running win7 x64 and 1 desktop running win XP, all of them don't crash the server. My desktop running win7 x64 does, BUT only this server crashes. If I try simultaneous transfers on any of the other servers I have built they don't crash.

 

On my server running 4.7 I use this in the config/go script:

ulimit -n 20000;/usr/local/sbin/emhttp &

instead of

/usr/local/sbin/emhttp &

 

emhttp is invoking samba, and it needs to have the open file limit raised in 4.7 to deal with windows7 inability to close files properly.

 

read about it all here:

http://lime-technology.com/forum/index.php?topic=9007.msg85968#msg85968

Link to comment

Possibly because it is deprecated, as its section title indicates:

Version 4.X Support (deprecated - use General Support above)

Windows7 does have an issue with not closing files.  eventually unRAID would run out of open file descriptors.

 

Joe L.

 

That's interesting.  I had not heard that, but I have had issues moving files or folders stored on Server 2008 that have been accessed or viewed on win 7.  In some cases simply going in and back out of a folder makes it generated a "file is open" error when you try to move it. 

 

That gives me somewhere to look for a solution, but now wondering if there is one.

 

Anyway, thanks, and don't mean to hijack the thread.

Link to comment
  • 3 weeks later...
  • 3 months later...

Well I finally got a chance to do some testing. It turns out that its the Ethernet port that is causing the issue. How I came to that conclusion is I put a different usb with unRAID installed on it and a test drive into my server. It crashed on simultaneous transfers, that exact same config in a different server ran fine. I suspected it might be happening because of the Ethernet port, so I threw a 10/100 PCI Ethernet card in. No crashes!

 

So the issue is with the onboard ethernet port. I would really rather use the onboard ethernet because I don't want to use up a slot for an ethernet adapter. My onboard ethernet chipset is Realtek 8111C.

 

Any suggestion on how I could configure it so that it will not cause unRAID to crash? Possibly a driver issue??

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.