OMV Machine hangs randomly on large file transfers to OMV

  • I've had a random hang that has occurred about 4 times total when transferring large amount of data from Windows 8.1 or Windows 10 to OMV.

    OMV to Windows 8.1 (SMB): No problem!
    OMV to Windows 10 (SMB): No problem!
    Synology NAS to OMV (NFS): No Problem!
    Windows 8.1 (SMB) to OMV: Random Freezes
    Windows 10 (SMB) to OMV: Random Freezes

    Always the random problem comes when transferring from Windows 8.1/10 to OMV over Samba. Sometimes it finishes the copy okay, sometimes it hangs. Randomly Windows copy progress freezes and OMV becomes unresponsive. Can't access it through the main Web GUI and I have to power it down at the machine with the power button. It does recognize I hit the power button and shuts itself down via software.

    The board is new ASRock N3150DC-ITX. New memory (Crucial 8 GB), new SSD (Samsung - Storage/Intel - OS), etc. The fact that the issue is asymmetric (issue is only to machine) and only happens with Samba (NFS is okay) leads me to believe this is a Samba issue. Perhaps either a network driver issue or a Samba issue.

    Any ideas on where to begin debugging it? Which logs to look at, ideas to try out? Thanks!

  • Any ideas on where to begin debugging it?

    Try two virtual machines one with wheezy (samba 3.6) , one with jessie (samba 4.1) you can copy smb.conf from omv. If 4.1 solves the issue you can try an install samba 4.1 in omv wheezy using the samba backport package. There is no downgrade process if you choose the backport path, unless you know your way around CLI, linux and apt-get. I've used the samba bpo package in OMV and i haven't encounter any issues.

  • I did some reading and there have been various posts about how the kernel's use of the r8169 drivers can cause issues for r8168/8111 hardware.

    Some of the failure descriptions are spot-on for what I am experiencing:

    Are there any cautions about downloading/applying the latest r8168/8111 drivers from RealTek's website?

    I still wonder why I only see this with Samba. I transferred half a TB with NFS and it was rock solid. It was only with Samba that I get the random network lockup. I suppose it could be the way Samba is interacting with the driver that NFS isn't. So potentially updating Samba might be a viable path as well.

  • I can't say anything for sure. Several years ago I got so fed up with Realtek. I always have spare Intel NICs laying around now. We are getting closer to OMV 3.0. Maybe Jessie backports will solve the issue. Good Luck!!

  • Good advice, thanks tekkb and subzero!

    My general plan:
    1) Try the newest driver. Keep the kernel & samba default.
    2) Try the samba 4.1 backport.
    3) Try the kernel backport (and redo the driver for the new kernel, right?)
    4) Buy a $25 Intel NIC

    Regarding the Samba Backport. Do you suggest anything different than these instructions?

    Add the following line to /etc/apt/sources.list:
    deb wheezy-backports main
    Update the package index:
    # apt-get update
    Install smbclient deb package:
    # apt-get install smbclient

    For the kernel backport I'd use the OMV Extras tab automation.

  • That's not the samba server. I though you wanted to test against windows clients

    You are correct. Samba server is what I'm after. I found that on the web and didn't realize it was talking about a Samba Client. If I substitute in the equivalent name for the samba server package instead of 'smbclient', is that how you'd recommend getting the backport?


    You can upgrade to the wheezy backport kernel if you have not done so in OMV Extras with a button in the Web GUI.

    Yep, nice feature!

  • I can't exaclty, remember sort of like say a package wasn't installable, then you pick that package1 and do apt-get install package1/wheezy-backports then says the same package2 wasn't installable, so you go on again apt-get install package2/wheezy-backports and on until the last one, then go back installing. Sort like resolving in reverse

  • The samba backport installed without problem.

    Exact steps I used for anyone interested:

    There was the question of whether to use a new smb.conf or the existing. In VirtualBox I used both to be able to examine the differences. Upon inspection they were very similar so I used the existing smb.conf file. It works except for if the recycle bin is active it won't allow you to browse into the shared folder and it will give the following error in the syslog file (once the logging level is turned up a little):

    Jan 3 18:19:12 OMVTest smbd[5376]: Error loading module '/usr/lib/x86_64-linux-gnu/samba/vfs/': /usr/lib/x86_64-linux-gnu/samba/vfs/ cannot open shared object file: No such file or directory
    Jan 3 18:19:12 OMVTest smbd[5376]: [2016/01/03 18:19:12.213405, 0] ../source3/smbd/vfs.c:184(vfs_init_custom)
    Jan 3 18:19:12 OMVTest smbd[5376]: error probing vfs module 'recycle': NT_STATUS_UNSUCCESSFUL
    Jan 3 18:19:12 OMVTest smbd[5376]: [2016/01/03 18:19:12.213688, 0] ../source3/smbd/vfs.c:349(smbd_vfs_init)
    Jan 3 18:19:12 OMVTest smbd[5376]: smbd_vfs_init: vfs_init_custom failed for recycle
    Jan 3 18:19:12 OMVTest smbd[5376]: [2016/01/03 18:19:12.213938, 0] ../source3/smbd/service.c:640(make_connection_snum)
    Jan 3 18:19:12 OMVTest smbd[5376]: vfs_init failed for service Movies
    Jan 3 18:19:12 OMVTest smbd[5376]: [2016/01/03 18:19:12.214634, 0] ../lib/util/modules.c:48(load_module)

    So minus the recycle option it seems to be working fine.

  • I was doing some reading up on the vfs objects. Pretty cool in how they intercept the requests and can selectively perform actions.

    Anyway, so it should be looking for the shared object files:
    Here: /usr/lib/samba/vfs
    Not Here: /usr/lib/x86_64-linux-gnu/samba/vfs/

    I'm not sure where it picked up the extra x86_64-linux-gnu in the path. If I can find where that is specified I could correct it.

  • Ha! Nailed it. I guess they moved the default location and samba-vfs-modules wasn't installed by default.

    I used:
    apt-get install samba-vfs-modules

    And that fixed it. Bingo!

    Edit: Correcting my notes above with the new information.

  • So, did moving to Samba 4 fix the problem? I have a problem very similar. I have a Dell Optiplex with Intel Gigabit NIC. A little background first: I was running an older version of OMV (Not sure version anymore but was of 2.x branch), and copying was working fine other than a pause after each file copy, but it was bearable even with big files. I know at this point I had made no changes to the Samba stuff because once I got the shares working it just worked. Well I had to take down my server for a few days because of moving rooms, and when I brought it back up I had hard drive errors on the O/S drive. Other drives tested fine. So I decided to just start clean. Installed the version of StoneBurner in my sig and went to work. First thing I did was recreate my shares and make sure network saw them and I could copy to them (Permissions). Copying started off fine at a respectable for my wireless 40MB/s. Then at about 40-50% the copy just stalls and then starts creeping along at ~800KB/s. I tried adding things to the Samba extra options, tried to adjust performance and acoustic settings for the drives, changed cables and switches that my server is plugged into. Previously was into a 10/100 and now into a Gigabit that goes straight into the wifi router. Any ideas?? I'll start a new topic if I need to.

    Thanks Guys.

    OMV: 2.2.1 (Stoneburner)
    Kernel: 3.16.0-0.bpo.4-amd64

  • I have a large degree of confidence that it fixed it, but since it was an intermittent problem to begin with, it makes it difficult to know for certain if I'm 100% fixed. I haven't seen the same hang since I made the driver and samba version changes.

  • Reed: Thanks for advise. I had same issue. I followed your instructions and updated samba and kernel as tekkb suggested. Everything works like a charm.

    Thanks a lot guys. (Sorry for my english) :rolleyes:

  • Chiming in with another experience extremely similar to the OP.

    • New ASRock Motherboard, itx, using RTL8111GR NIC.
    • New storage, etc.
    • OMV 2.1 installed, a few things configured (GUI only).
    • Set up Samba share.
    • Attempt to transfer a block of files approx 11GB to the share from W10Px64. Explorer.exe hangs. OMV Web GUI became unavailable, SSH session hung.
    • Happened to have not yet disconnected LCD and keyboard. Was able to log in there and shutdown -r now.

    Unlike OP, my issue was EXTREMELY repeatable. I could make it happen every time with this large file transfer. Doing one or two 1GB files at a time would often succeed, but doing all of them at once, wouldn't make it 30%.

    Google left me wanting, thankfully other users have been bumping this old thread, so it was near the top of the Samba forum. My order of operations, with a reboot each time to see if there was any effectiveness:

    • Attempt latest driver from Realtek. This had results for me before in another situation (Lubuntu). This time, the resulted in errors that I did not diagnose (I am Windows IT at work, Linux drivers I don't quite get). This made me lose ethernet until I rebooted. No improvement after reboot.
    • Backport samba and samba VFS. These completed cleanly with no errors. No improvement after reboot.
    • Install 3.16 kernel using the Web GUI feature in OMV Extras. Immediate improvement after reboot.

    I have now transferred, deleted, and re-transferred the file selection over and over again a dozen times, with no issues the entire time.

    However, the upgrade to 3.16 did seem to break the VirtualBox plugin from OMV Extras. On first reboot, I did notice many error messages regarding VB flash by before the login prompt. Sure enough, when I check the GUI, the VB service was enabled, but not running.

    I didn't spend any time troubleshooting it. I hadn't yet created any VMs, only a user name. So, I just uninstalled it through the Web GUI, reboot, reinstall through the Web GUI.

    That seemed to work, however, when I was re-configuring VB, I noticed the handy "recompile for backport kernels" option I missed before. Very thoughtful feature, which I missed, thankfully it only cost me ten minutes and a reboot.

  • I'm having the same problem. But after doing this

    Add the following line to /etc/apt/sources.list:
    deb wheezy-backports mainapt-get
    apt-get -t wheezy-backports install samba

    it still remains. What else should I do?
    If it matters, I see this in the log before failure

    8169 0000:02:00.0: eth0: link down

    Thank you in advance!

    UPD: The problem just turned to be not the same. Fail occurs even when copying via FTP. Not randomly, but instant after begining copy process

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!