August 24, 201411 yr Hello, I am having a major issue with samba on unRAID 6.0 beta 6 and 7. Samba drops connection in a middle of file copying of large files 5+ GB. I've turned the log on and got the following messages: STATUS=daemon 'smbd' finished starting up and ready to serve connections WARNING: The "null passwords" option is deprecated [2014/08/24 09:15:03.310930, 1] ../source3/smbd/service.c:1130(close_cnum) windows81pro-vm (ipv4:192.168.0.127:50350) closed connection to service home.dir [2014/08/24 09:16:58.905444, 1] ../source3/smbd/service.c:1130(close_cnum) windows81pro-vm (ipv4:192.168.0.127:50354) closed connection to service home.dir Any help/suggestions/fixes will be greatly appreciated. My system is running on SuperMicro X10SLH-F motherboard with 24GB of ECC RAM and 14x Seagate ST4000DM000 (4TB) hard drives. Thanks, Michael Abadjiev
August 24, 201411 yr Please refer to the Guidelines for Defect Reports post. You did not provide enough information for me to troubleshoot this problem - which is another way of saying: I can transfer huge files all day long and never see this issue. There must be something unique about your config/environment.
August 24, 201411 yr Author As requested, here is the information unRAID OS Version: unRAIDServer-6.0-beta7-x86_64 Description: I am having a major issue with samba on unRAID 6.0 beta 6 and 7. Samba drops connection in a middle of file copying of large files 5+ GB, so the file is partially copied. I've turned the samba log on and got the following messages: STATUS=daemon 'smbd' finished starting up and ready to serve connections WARNING: The "null passwords" option is deprecated [2014/08/24 09:15:03.310930, 1] ../source3/smbd/service.c:1130(close_cnum) windows81pro-vm (ipv4:192.168.0.127:50350) closed connection to service home.dir [2014/08/24 09:16:58.905444, 1] ../source3/smbd/service.c:1130(close_cnum) windows81pro-vm (ipv4:192.168.0.127:50354) closed connection to service home.dir How to reproduce: Stock setup of samba Expected results: Should copy the file as in version 5.0.5 Actual results: Copying is terminated unexpected. Other information: Works fine on unRAID 5.0.5
August 24, 201411 yr Where is the Windows 8.1 pro VM running? Is this on the unRAID server or another system in your setup?
August 24, 201411 yr Author Hello jonp, Thanks for your instant response. Windows 8.1 Pro is running on my Mac under VMWare Fusion. The samba drop happened on all of my Macs and Windows Virtual machines, I don't have physical Windows machines. Also, I've noticed that parity check coincidently was running on the server (unRAID 6.0 beta7) so I've stopped it. I was copying 29GB ova file and samba drops connection after 5GB of copying. I just found that 11GB file copy is successful (tried few times) Thanks, mabadjiev
August 25, 201411 yr Author Just FYI. I found that the problem is really bad if the parity check is running. So, to recreate the problem: 1. Start parity check with error correction/fix. 2. Wait few minutes and start copying a large file (more than 10 GB) I was able to recreate the issue multiple times now. Thanks, mabadjiev
October 2, 201411 yr Is this still persisting for you in the current beta? I cannot reproduce from my end.
October 2, 201411 yr Author Thanks for your reply. unRAID 6 beta 10a is a bit better, but still happens with large files, I've tried 29GB file without parity check running and it happened. If you turn on parity check happens instantly.
October 2, 201411 yr Ok, to make sure we're clear: 1) unRAID server booted, no plugins installed or running? 2) From Windows VM, you connect using file explorer to //tower (or whatever your server name is) 3) You begin a file transfer where the source of the content is inside the vdisk of the Windows VM and copy to an unRAID user share over SMB 4) Copy proceeds like normal, but cuts out in the middle somewhere. Cuts out faster if this is done during a parity check. Correct?
October 2, 201411 yr A few follow up questions: 1) Is this a cache enabled or cache only user share? 2) What write speed do you witness during the file transfer? Does it fluctuate or remain consistent? 3) Does it ever pause in the midst of the transfer to only resume moments later? 4) Is this a private or secure user share? I'm testing a 40GB file right now to see if I can recreate in beta 10a. I am not running a parity check, but will re-run the test after this copy completes if it doesn't cut out...
October 2, 201411 yr unRAID 6 beta 10a is a bit better, but still happens with large files, I've tried 29GB file without parity check running and it happened. If you turn on parity check happens instantly. Please provide the syslog for this session, zipped if necessary.
October 2, 201411 yr Author Yes, I've tried all that. I also tried from a Mac - same result. I have two unRAID servers and happens on both. I even went one step further and replace the switch that I was using - same thing. My Servers are: SuperMicro X10SLH-F with 2x Supermicro AOC-SAS2LP-MV8 total 15 disks and Intel Xeon E3-1245V3 Haswell 3.4GHz 24GB RAM and ASRock Motherboard E3C226D2I with one SupermicroAOC-SASLP-MV8 total 8 disks and Intel Xeon E3-1230 V3 3.3GHz Quad-Core Processor 16GB RAM Thanks.
October 2, 201411 yr Well my test completed with no "drop" and now it's running again while a parity check is going. The write speed is definitely reduced (obviously) but it's still going. We'll keep an eye on this and see if it drops out.
October 3, 201411 yr Ok, I'm not an expert at decyphering syslogs, so someone else may need to examine this, but a simple cat syslog | grep error showed me this: Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata8: end_device-1:1: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata8: end_device-1:1: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata9: end_device-1:2: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata8: end_device-1:1: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata9: end_device-1:2: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata10: end_device-1:3: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata8: end_device-1:1: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata9: end_device-1:2: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata10: end_device-1:3: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata11: end_device-1:4: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata8: end_device-1:1: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata9: end_device-1:2: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata10: end_device-1:3: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata11: end_device-1:4: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata12: end_device-1:5: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata8: end_device-1:1: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata9: end_device-1:2: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata10: end_device-1:3: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata11: end_device-1:4: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata12: end_device-1:5: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata13: end_device-1:6: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata8: end_device-1:1: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata9: end_device-1:2: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata10: end_device-1:3: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata11: end_device-1:4: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata13: end_device-1:6: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata12: end_device-1:5: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata14: end_device-1:7: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata15: end_device-8:0: dev error handler Not sure what that means exactly (might need Tom or someone else to review). Still going to pour through those logs some more. Also, there is a log file under /var/log/samba I think (maybe two). Can you post those as well for us to examine?
October 3, 201411 yr Just an FYI, two big copies complete in my tests today (first was 46GB, second was over 50GB) and the second test was while a parity check was running. No cut outs, no issues. Lack of repeatability could mean this isn't a bug, but another problem with the system. Not ruling out the bug possibility though until we know that's the case...
October 3, 201411 yr Author Interesting, these errors are on September 29, 2014, however I've got the error today.... Something to be investigated I would think.
October 3, 201411 yr Sep 29 20:00:22 unraid kernel: sas: ata7: end_device-1:0: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata8: end_device-1:1: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata9: end_device-1:2: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata10: end_device-1:3: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata11: end_device-1:4: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata13: end_device-1:6: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata12: end_device-1:5: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata14: end_device-1:7: dev error handler Sep 29 20:00:22 unraid kernel: sas: ata15: end_device-8:0: dev error handler Those aren't error lines, just lines where the 'dev error handler' reports that it has completed setting up a drive. It's a very noisy handler, with a bug in its logging the end of each setup, but completely harmless. I saw no issues with the drive systems. The only Samba stop shown in this syslog is at Sep 30 19:59:30, where all services are stopped then restarted. It looks intentional to me, occurs almost exactly 24 hours after booting, so I don't think it's the Samba drop you were referring to. In fact, I'm wondering if the messages earlier you posted about smbd dropping were from the Mac, not the UnRAID server. Can you confirm where you saw them? The only other drops I saw were SSH sessions, and they looked intentional by user. (but I could be wrong) There is stuff here that's new to me. When you have one of these Samba drops, try going to another machine and trying a Samba transfer to your UnRAID server, to check whether it's still working there. [quote author=mabadjiev link=topic=34799.msg331240#msg33124 0 date=1412300127] Interesting, these errors are on September 29, 2014, however I've got the error today.... Something to be investigated I would think. In your syslog is the following line: Sep 29 20:00:22 unraid kernel: rtc_cmos 00:02: setting system clock to 2014-09-30 02:59:59 UTC (1412045999) So I suspect your timezone setting (or time offset) may not be set correctly. Perhaps a sign reversal? There's often confusion over whether the offset is a plus from UTC or a minus. Try checking your time settings, reversing the sign perhaps.
October 3, 201411 yr Author Hello, The disconnect happens from any OS accessing the server via CIFS. I've tried to turn the SAMBA logging on - nothing meaningful so far, it just says - Client close connection. As far as the time setting I believe they are correct, internally unRAID is probably using UTC (see attached) Thanks for your time.
October 3, 201411 yr Hello, The disconnect happens from any OS accessing the server via CIFS. I've tried to turn the SAMBA logging on - nothing meaningful so far, it just says - Client close connection. As far as the time setting I believe they are correct, internally unRAID is probably using UTC (see attached) Thanks for your time. This is sounding more and more like a client issue, not unRAID. All my transfer attempts from various devices seem to work fine to my systems (multiple testing).
October 3, 201411 yr Author Interesting on unRAID 5.0.5 none of this happens - same equipment. I am not quite sure what do you mean by 'client issue'. I was able to recreate the problem even on Linux (ubuntu 14.04 LTS) while mounting share via CIFS. So if all the clients Linux, Windows and Mac are having this issue, I would think more of a client-server issue and since that does not happen on unRAID 5.0.5 more of a server issue.
October 3, 201411 yr Interesting on unRAID 5.0.5 none of this happens - same equipment. I am not quite sure what do you mean by 'client issue'. I was able to recreate the problem even on Linux (ubuntu 14.04 LTS) while mounting share via CIFS. So if all the clients Linux, Windows and Mac are having this issue, I would think more of a client-server issue and since that does not happen on unRAID 5.0.5 more of a server issue. Good point. This is just really odd that I can't recreate. Need to ponder this one for a little bit.
October 4, 201411 yr OK, let's try this. Do you have it so you can browse your disk shares over SMB directly? If so, can you try an SMB copy to just a single disk for me? If that fails, stop the array, turn off user shares, then start the array and repeat that test again. PS: let me know if you need more detailed instructions on how to do all of that.
Archived
This topic is now archived and is closed to further replies.