September 12, 200916 yr Hi, I've been using my 4.5 Beta 6 unRAID box quite happily now for the last few months with no issues - until I tried to connect to it yesterday and none of the SAMBA shares worked. I am getting the message STARTED, 5 disks in array. Parity is Valid:. Last parity check < 1 day ago with no sync errors. ; SAMBA is STOPPED, Shared drives will not be visible on the LAN. My setup is as follows: Core2Duo E6600 2GB RAM 1 x 2 TB WDD Green Drive (Parity) 4 x 1.5 TB Seagate HDD (Data) Antec P180 Case (lotsa room and ventilation) uuMenu I have attached the full syslog but I can't seem to find anything that would indicate the cause of the problem. I have the machine automatically shutting down (through the WebUI using a Badboy http://www.badboy.com.au/script - basically it clicks the web ui buttons - so it's all done properly - ie stop and then shutdown). I am a (Java) developer by trade and primarily use Windoze and OS X but occasionally Linux. ie I am not a total newbie but that's about as much as I would say about my Linux nerdfu :-) Investigation so far As the message above indicates I have run a complete parity check and the array seems AOK (0 errors reported). I have performed a cursory examination of the files - ie was able to list the individual drive contents using uuMenu's "File Browser" and the files appeared to be present. Given they were large media files it stated that it was not possible to view them. I have looked through the syslog (it only reports the last day as I shutdown daily and I tried the "old faithful" IT fix of "turn it off/on" and I couldn't find any kernal panics or any other causes of problems. I did find several non-zero exit codes near the samba section which may show the result of the problem The only other things that I can think of that may possibly affect this are: I recently went away for a couple of weeks and shutdown the machine for that duration (but I did it through the WebUI and then the power point - it was setup to automatically wakeup in the BIOS daily) I was having trouble copying a couple of large files onto my shares as they appeared to be filled upon one of the drives but not the share - likely setting the split level too low. I think I tried connecting to the drive share directly and put the file into the appropriate folder. ie /mnt/disk3/share Could someone with more unRAID / linux experience please advise on what to try next? Do I need to do a chkdsk or equivalent upon the USB boot drive (as was suggested for another poster - http://lime-technology.com/forum/index.php?topic=3880.0? Perhaps a chkdsk (reiserfsck?) for the individual volumes (not sure how to do this as I'm not a Linux user)? Something else? thanks for listening :- ) belorion SYSYLOG FRAGMENT (full file attached) Sep 11 21:43:15 Tower rpc.statd[1287]: Version 1.1.4 Starting Sep 11 21:43:15 Tower emhttp: unRAID System Management Utility version 4.5-beta6 Sep 11 21:43:15 Tower emhttp: Copyright (C) 2005-2009, Lime Technology, LLC Sep 11 21:43:15 Tower emhttp: Pro key detected, GUID: 1B1C-0B29-0000-000000000245 Sep 11 21:43:15 Tower emhttp: shcmd (1): cp /boot/config/passwd /etc Sep 11 21:43:15 Tower emhttp: shcmd (2): cp /boot/config/smbpasswd /etc/samba/private Sep 11 21:43:15 Tower emhttp: Device inventory: Sep 11 21:43:15 Tower emhttp: pci-0000:00:1f.2-scsi-0:0:0:0 (sda) ata-ST31500341AS_9VS20M4T Sep 11 21:43:15 Tower emhttp: pci-0000:00:1f.2-scsi-0:0:1:0 (sdb) ata-WDC_WD20EADS-00R6B0_WD-WCAVY0100163 Sep 11 21:43:15 Tower emhttp: pci-0000:00:1f.2-scsi-1:0:0:0 (sdc) ata-ST31500341AS_9VS21EV7 Sep 11 21:43:15 Tower emhttp: pci-0000:00:1f.5-scsi-0:0:0:0 (sdd) ata-ST31500341AS_9VS20RC4 Sep 11 21:43:15 Tower emhttp: pci-0000:00:1f.5-scsi-1:0:0:0 (sde) ata-ST31500341AS_9VS21B3M Sep 11 21:43:15 Tower emhttp: shcmd (3): rmmod md-mod >>/var/log/go 2>&1 Sep 11 21:43:15 Tower emhttp: _shcmd: shcmd (3): exit status: 1 Sep 11 21:43:15 Tower emhttp: shcmd (4): modprobe md-mod super=/boot/config/super.dat slots=8,16,8,0,8,32,8,48,8,64,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 >>/var/log/go 2>&1 Sep 11 21:43:15 Tower kernel: md: unRAID driver 0.95.2 installed Sep 11 21:43:16 Tower kernel: md: xor using function: pIII_sse (8855.200 MB/sec) Sep 11 21:43:16 Tower kernel: md: import disk0: [8,16] (sdb) WDC WD20EADS-00R6B0 WD-WCAVY0100163 offset: 63 size: 1953514552 Sep 11 21:43:16 Tower kernel: md: import disk1: [8,0] (sda) ST31500341AS 9VS20M4T offset: 63 size: 1465137496 Sep 11 21:43:16 Tower kernel: md: import disk2: [8,32] (sdc) ST31500341AS 9VS21EV7 offset: 63 size: 1465138552 Sep 11 21:43:16 Tower kernel: md: import disk3: [8,48] (sdd) ST31500341AS 9VS20RC4 offset: 63 size: 1465138552 Sep 11 21:43:16 Tower kernel: md: import disk4: [8,64] (sde) ST31500341AS 9VS21B3M offset: 63 size: 1465138552 Sep 11 21:43:16 Tower emhttp: shcmd (5): rm /etc/samba/smb-shares.conf >/dev/null 2>&1 Sep 11 21:43:16 Tower emhttp: _shcmd: shcmd (5): exit status: 1 Sep 11 21:43:16 Tower emhttp: shcmd (6): cp /etc/exports- /etc/exports Sep 11 21:43:16 Tower emhttp: shcmd (7): killall -HUP smbd Sep 11 21:43:16 Tower emhttp: _shcmd: shcmd (7): exit status: 1 Sep 11 21:43:16 Tower emhttp: shcmd (: /etc/rc.d/rc.nfsd restart | logger Sep 11 21:43:18 Tower kernel: md: import disk0: [8,16] (sdb) WDC WD20EADS-00R6B0 WD-WCAVY0100163 offset: 63 size: 1953514552 Sep 11 21:43:18 Tower kernel: md: import disk1: [8,0] (sda) ST31500341AS 9VS20M4T offset: 63 size: 1465137496 Sep 11 21:43:18 Tower kernel: md: import disk2: [8,32] (sdc) ST31500341AS 9VS21EV7 offset: 63 size: 1465138552 Sep 11 21:43:18 Tower kernel: md: import disk3: [8,48] (sdd) ST31500341AS 9VS20RC4 offset: 63 size: 1465138552 Sep 11 21:43:18 Tower kernel: md: import disk4: [8,64] (sde) ST31500341AS 9VS21B3M offset: 63 size: 1465138552 Sep 11 21:43:18 Tower emhttp: shcmd (9): /usr/local/sbin/set_ncq sdb 1 | logger Sep 11 21:43:18 Tower emhttp: shcmd (10): /usr/local/sbin/set_ncq sda 1 | logger Sep 11 21:43:18 Tower emhttp: shcmd (11): /usr/local/sbin/set_ncq sdc 1 | logger Sep 11 21:43:18 Tower emhttp: shcmd (12): /usr/local/sbin/set_ncq sdd 1 | logger Sep 11 21:43:18 Tower emhttp: shcmd (13): /usr/local/sbin/set_ncq sde 1 | logger Sep 11 21:43:18 Tower kernel: mdcmd (3): start Sep 11 21:43:18 Tower kernel: md: import disk0: [8,16] (sdb) WDC WD20EADS-00R6B0 WD-WCAVY0100163 offset: 63 size: 1953514552 Sep 11 21:43:18 Tower kernel: md: import disk1: [8,0] (sda) ST31500341AS 9VS20M4T offset: 63 size: 1465137496 Sep 11 21:43:18 Tower kernel: md: import disk2: [8,32] (sdc) ST31500341AS 9VS21EV7 offset: 63 size: 1465138552 Sep 11 21:43:18 Tower kernel: md: import disk3: [8,48] (sdd) ST31500341AS 9VS20RC4 offset: 63 size: 1465138552 Sep 11 21:43:18 Tower kernel: md: import disk4: [8,64] (sde) ST31500341AS 9VS21B3M offset: 63 size: 1465138552 Sep 11 21:43:18 Tower kernel: unraid: allocated 11384kB Sep 11 21:43:18 Tower kernel: md1: running, size: 1465137496 blocks Sep 11 21:43:18 Tower kernel: md2: running, size: 1465138552 blocks Sep 11 21:43:18 Tower kernel: md3: running, size: 1465138552 blocks Sep 11 21:43:18 Tower kernel: md4: running, size: 1465138552 blocks Sep 11 21:43:18 Tower emhttp: shcmd (14): mkdir /mnt/disk2 Sep 11 21:43:18 Tower emhttp: shcmd (14): mkdir /mnt/disk1 Sep 11 21:43:18 Tower emhttp: shcmd (15): mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md1 /mnt/disk1 >/dev/null 2>&1 Sep 11 21:43:18 Tower emhttp: shcmd (15): mkdir /mnt/disk3 Sep 11 21:43:18 Tower kernel: mdcmd (5): check Sep 11 21:43:18 Tower kernel: md: recovery thread woken up ... Sep 11 21:43:18 Tower emhttp: shcmd (15): mkdir /mnt/disk4 Sep 11 21:43:18 Tower emhttp: shcmd (16): mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md2 /mnt/disk2 >/dev/null 2>&1 Sep 11 21:43:18 Tower emhttp: shcmd (17): mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md3 /mnt/disk3 >/dev/null 2>&1 Sep 11 21:43:18 Tower emhttp: shcmd (18): mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md4 /mnt/disk4 >/dev/null 2>&1 Sep 11 21:43:18 Tower kernel: md: recovery thread has nothing to resync Sep 11 21:43:18 Tower kernel: ReiserFS: md1: found reiserfs format "3.6" with standard journal Sep 11 21:43:18 Tower kernel: ReiserFS: md1: using ordered data mode Sep 11 21:43:18 Tower kernel: ReiserFS: md2: found reiserfs format "3.6" with standard journal Sep 11 21:43:18 Tower kernel: ReiserFS: md2: using ordered data mode Sep 11 21:43:18 Tower kernel: ReiserFS: md4: found reiserfs format "3.6" with standard journal Sep 11 21:43:18 Tower kernel: ReiserFS: md4: using ordered data mode Sep 11 21:43:18 Tower kernel: ReiserFS: md3: found reiserfs format "3.6" with standard journal Sep 11 21:43:18 Tower kernel: ReiserFS: md3: using ordered data mode Sep 11 21:43:18 Tower kernel: ReiserFS: md1: journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Sep 11 21:43:18 Tower kernel: ReiserFS: md1: checking transaction log (md1) Sep 11 21:43:18 Tower kernel: ReiserFS: md2: journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Sep 11 21:43:18 Tower kernel: ReiserFS: md2: checking transaction log (md2) Sep 11 21:43:18 Tower kernel: ReiserFS: md4: journal params: device md4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Sep 11 21:43:18 Tower kernel: ReiserFS: md4: checking transaction log (md4) Sep 11 21:43:18 Tower kernel: ReiserFS: md3: journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Sep 11 21:43:18 Tower kernel: ReiserFS: md3: checking transaction log (md3) Sep 11 21:43:18 Tower kernel: ReiserFS: md2: Using r5 hash to sort names Sep 11 21:43:18 Tower kernel: ReiserFS: md3: Using r5 hash to sort names Sep 11 21:43:18 Tower kernel: ReiserFS: md4: Using r5 hash to sort names Sep 11 21:43:19 Tower kernel: ReiserFS: md1: Using r5 hash to sort names Sep 11 21:43:19 Tower kernel: can't shrink filesystem on-line Sep 11 21:43:19 Tower last message repeated 3 times Sep 11 21:43:19 Tower emhttp: shcmd (22): rm /etc/samba/smb-shares.conf >/dev/null 2>&1 Sep 11 21:43:19 Tower emhttp: shcmd (23): cp /etc/exports- /etc/exports Sep 11 21:43:19 Tower emhttp: shcmd (24): mkdir /mnt/user Sep 11 21:43:19 Tower emhttp: shcmd (25): /usr/local/sbin/shfs /mnt/user -o allow_other,attr_timeout=0,entry_timeout=0,negative_timeout=0 Sep 11 21:43:19 Tower emhttp: shcmd (26): cp /var/spool/cron/crontabs/root- /var/spool/cron/crontabs/root Sep 11 21:43:19 Tower emhttp: shcmd (27): echo '# Generated mover schedule:' >>/var/spool/cron/crontabs/root Sep 11 21:43:19 Tower emhttp: shcmd (28): echo '40 3 * * * /usr/local/sbin/mover 2>&1 | logger' >>/var/spool/cron/crontabs/root Sep 11 21:43:19 Tower emhttp: shcmd (29): crontab /var/spool/cron/crontabs/root Sep 11 21:43:20 Tower emhttp: shcmd (30): killall -HUP smbd Sep 11 21:43:20 Tower emhttp: _shcmd: shcmd (30): exit status: 1 Sep 11 21:43:20 Tower emhttp: shcmd (31): /etc/rc.d/rc.nfsd restart | logger Sep 11 21:43:22 Tower ntpd[1273]: synchronized to 192.189.54.33, stratum 2 Sep 11 21:43:57 Tower in.telnetd[1480]: connect from 192.168.0.41 (192.168.0.41) Sep 11 21:44:00 Tower login[1481]: ROOT LOGIN on `pts/0' from `192.168.0.41' Sep 11 22:05:07 Tower kernel: mdcmd (55): check Sep 11 22:05:07 Tower kernel: md: recovery thread woken up ... Sep 11 22:05:07 Tower kernel: md: recovery thread checking parity... Sep 11 22:05:07 Tower kernel: md: using 1152k window, over a total of 1953514552 blocks. Sep 12 04:05:14 Tower emhttp: shcmd (32): /usr/sbin/hdparm -y /dev/sda >/dev/null Sep 12 04:05:14 Tower emhttp: shcmd (33): /usr/sbin/hdparm -y /dev/sdc >/dev/null Sep 12 04:05:14 Tower emhttp: shcmd (34): /usr/sbin/hdparm -y /dev/sdd >/dev/null Sep 12 04:05:14 Tower emhttp: shcmd (35): /usr/sbin/hdparm -y /dev/sde >/dev/null Sep 12 05:19:39 Tower kernel: md: sync done. time=25761sec rate=75832K/sec Sep 12 05:19:39 Tower kernel: md: recovery thread sync completion status: 0 Sep 12 06:19:47 Tower emhttp: shcmd (36): /usr/sbin/hdparm -y /dev/sdb >/dev/null Sep 12 09:43:15 Tower dhcpcd[1265]: sending DHCP_REQUEST for 192.168.0.102 to 192.168.0.1 Sep 12 09:43:15 Tower dhcpcd[1265]: dhcpIPaddrLeaseTime=43200 in DHCP server response. Sep 12 09:43:15 Tower dhcpcd[1265]: dhcpT1value is missing in DHCP server response. Assuming 21600 sec Sep 12 09:43:15 Tower dhcpcd[1265]: dhcpT2value is missing in DHCP server response. Assuming 37800 sec Sep 12 09:43:15 Tower dhcpcd[1265]: DHCP_ACK received from (192.168.0.1)
September 15, 200916 yr Sorry, I haven't been around much lately. The syslog looks good, except for the error returns after the attempts to start Samba. I don't see any evidence of file system corruption, either on the flash drives or any of the data drives. These error returns ("_shcmd: shcmd (#): exit status: 1") appear very generic, so I *think* that the value 1 here is not a specific error value, but simply indicates a non-zero return. In comparing with other syslogs, the return of 1 seems normal following the "rmmod md-mod", probably just clearing the structures before loading them, error first appeared in v4.2 betas. It also appears to be currently normal following the "rm /etc/samba/smb-shares.conf" (introduced in v4.5-beta2), normal as of v4.5-beta4 through v4.5-beta6. This error did not occur in v4.5-beta3 (or beta2), and may be related to all of the Samba changes around that release. I note there were related Cache disk changes around this time too, which may have inadvertently resulted in the current Cache disk performance problem. Prior to v4.5-beta6, the entity reporting the error code was shcmd, but as of beta6 is now _shcmd with a preceding underscore. That looks like either a helper function or a custom shcmd. Clearly, there is ongoing work here, beta work. There is every indication that Tom had intended a beta7 with fixes to whatever his and our beta testing found, but life seems to have intervened. Once he is back, I'm sure this will be cleaned up. What is not normal is the error return after the "killall -HUP smbd" (in 2 places), which somewhat confusingly is the command that starts the Samba server running. This is where all diagnostic efforts should probably concentrate. I would isolate what is different about your setup, compared to a completely vanilla, stock unRAID. If you want to provide us with your setup, such as the contents of config/go, config/share.cfg, config/smb-extra.conf, and possibly config/ident.cfg, we might have some ideas. Otherwise, I would save your config files, return to a stock setup, then begin to add back any customizations, while testing for correct operation. Oops! Very sorry, but I'm a Linux noob, and confused the "killall -HUP" command with another. Time for me to do some more research myself, and wait for the true Linux experts to speak up.
September 17, 200916 yr Author Thanks RobJ, apologies for the delay in replying but RL has been keeping me away from my toys as of late. I have attached a tar of the config directory (as suggested) as well as the only customised script (excluding uuMenu) that I have installed. I don't believe the script actually worked (ie kicked off the cron scheduled parity_check) I have "installed" or downloaded the following packages: apcupsd-3.14.3-i486-1kjz.tgz* apcupsd-3.14.3-i486-1kjz.tgz.manual_install* apcupsd-unmenu-package.conf* bwm-ng-unmenu-package.conf* cxxlibs-unmenu-package.conf* file-4.21-i486-1.tgz* file-unmenu-package.conf* lsof-unmenu-package.conf* ntfs-3g-1.5130-unmenu-package.conf* pciutils-unmenu-package.conf* rc.local-unmenu-package.conf* smartctl-unmenu-package.conf* zip-unmenu-package.conf* By installation I only mean that I clicked on the link within the unRAID and unMENU applications to let it download and install whatever it required. I'm going to try "turning it off and on" to see if that will "fix" it :- ) thanks belorion The config.zip is actually just a config.tar (i had to rename the file in order to attach it)
September 17, 200916 yr I'm sorry, I don't see any important differences between your setup and mine, and your setup appears sufficiently vanilla that I don't see much likelihood in further 'slimming'. If you want to try, you can turn off User Shares and reboot. You can also delete the smbpasswd file, so that another can be generated. I don't hold out much hope that these changes will matter. A better test would be to rename the bzimage and bzroot files on your flash drive (eg. to bzroot45b6 and bzimage45b6), and copy the same 2 files from the v4.5-beta4 distro (LimeTech downloads), then boot and test. By doing this, you are reverting to v4.5-beta4, and reverting the Samba changes that may be affecting you. If that does not help, then revert even farther back to the current official release, v4.4.2 (the same way by copying bzroot and bzimage from the v4.4.2 distro). You can always return to the current beta version by deleting (or renaming) bzroot and bzimage, and renaming the original ones back. Otherwise, you are going to need help from more proficient Linux users, or Tom himself. By the way, another user appears to have had the same problem, in this thread. You should probably monitor it too. Please do try the advice and commands that Joe gives there too. Your monthly_parity_check script did not have a final end-of-line, and includes DOS end-of-lines throughout, so when executed, probably threw some error messages on the monitor similar to "/bin/sh^M :bad interpreter: No such file or directory". That "^M" represents a Control-M, or Carriage-Return which DOS uses in their end-of-lines, but which are not used by Linux. See the FAQ entry, "Why do my scripts have problems with end-of-lines?" I have attached a zipped copy of a correct monthly_parity_check.sh, which also includes an improvement from Joe that preserves the cron table across certain unRAID operations that might overwrite the table.
September 18, 200916 yr Author As it happens ... I tried the "old faithful" solution ... one more time (turn it off ... turn it on) ... And the SAMBA is working again :- ) !!!!!!!!!!! So that's good news ... but also not so good. Good that I can see my content again on the network ... Not so good because of the "transient" failure and fix. ie it can go away just as quickly as easily as it was fixed. Perhaps the bubbaraid "fix" mentioned in the other thread was just a coincidence ... perhaps it was a time based issue? perhaps it was the reboot ..and perhaps we'll never know.
September 18, 200916 yr I'm the owner of the bubbaraid solution. I'd been having random drop outs, and especially problems when transferring large files to the server. Then it just stopped. The restart fix had been working for a while till it didn't. I don't think it was just chance that it started working again. There were probably 20 or 30 restarts in between the failure and getting it back up again. I tried different flash drives, fresh installs, different NIC's, everything I could think of. I'm currently thinking that bubbaraid has it's own kernal and maybe it uses a different version of samba. It seems from what I've been reading here that there may be a problem with samba in 4.5 beta 6. Let's hope we see a new version soon. Good luck, I hope you solve your problems .
September 18, 200916 yr I have the same problem. Samba dies but web GUI runs fine. I see nothing in the Syslog. If I login to the webgui and stop & start the array all comes back after a few minutes. This *only* started occuring when I loaded Windows 7 on all of my Windows boxes. Unsure if Windows 7 is a common thread or not. On my Unraid at the office (running 4.4) I never have issues with this. Hardware is pretty much the same, only difference is number/size of drives and Unraid version. I too am at 4.5 beta 6.
September 20, 200916 yr I have the same problem. Samba dies but web GUI runs fine. I see nothing in the Syslog. If I login to the webgui and stop & start the array all comes back after a few minutes. This *only* started occuring when I loaded Windows 7 on all of my Windows boxes. Unsure if Windows 7 is a common thread or not. On my Unraid at the office (running 4.4) I never have issues with this. Hardware is pretty much the same, only difference is number/size of drives and Unraid version. I too am at 4.5 beta 6. That's interesting I just setup a system for my kids with Windows 7. I'd been having issues before that, but it always came back up after a restart. I just blamed it on a new router that I don't entirely trust. I really think that there is a samba issue with the latest version though. I'm also curious how many people with the same problem have a Windows 7 system on their network. There seems to be quite a few of us with the same problem, and nobody's discovered the cause, or the proper solution for that matter
Archived
This topic is now archived and is closed to further replies.