tazman

Thanks, how do I find out which md* devices I have and to which sd* ones they correspond? unRAID lists the disks as sd*.

Hi, I am having massive problems with 6.2. See my boiler plate for my config. After the upgrade from 6.1.9 everything seems to be running well and I added a second parity drive which was built without problems. Then I noticed that the system became unresponsive on shares and then the webgui. Eventually I had to take it down with poweroff as nothing else worked. Note that, out of habit, I tried powerdown first and that the powerdown script from 6.1.9 was still installed. After a restart everything first looked normal in the log but the array could not be started. I would sit on "Mounting disks..." and then messages about xfs errors, tainted mounts and eventually kernel traces and kernal panics appeared. Culminating with (not in the attached log): Kernel panic - not syncing: Fatal exception in interrupt Shutting down cpus with NMI Kernel Offset: disabled I reverted to 6.1.9. A memtest didnt show any errors. I was able to start the array. No errors occurred. Back on 6.1.9 xfs_repair -v (and -vn) reported the following error on ALL of my 14 data drives: bad primary superblock - bad magic number !!! I interrupted "attempting to find secondary superblock..." on a 3TB drive after it has been running without any results for 2 hours. The drive sdc1 which shows up with the "bad dir block magic!" error message in the log file is the second parity drive - at least after I downgraded which may have changed the drive numbering. I am at a loss now with what to do as I dont want to do something that makes things worse or even unrecoverable. I welcome your advice on what to do next. Thanks, Thomas syslog.txt

Hi, The recent surge of ransom trojan attacks made me worried about loosing all my unRAID data. Ie. a trojan infects any machine that is in my network (which could be a friend/guest), finds the unRAID shares and encrypts them. So I have ventured into locking down my array to: Grant only read access to the data needed by everybody Use a dedicated account for write-access I started with this security overview article from limetech: http://lime-technology.com/forum/index.php?topic=7047.0 I am kindly seeking your advice on the approach I have taken and the issues I face. This is for Windows/Android access. Only SMB access is used. NFS is disabled. Approach taken: Add a new user "backup" for write-access Set SMB.Security="Secure" for all user shares and set User Access for the user "backup" to "Read/Write" Media shares are exported with "Yes", others that do not require public access like shares used for backup are exported with "Yes (hidden)" Add a new share "Public" with security = Public to have a place for file sharing between users For each of the "disk*" shares: set Export=No so they are not accessible from outside Create a new user "backup" with the same password as on unRAID on my Windows machine that I use to perform work requiring write-access This seems to work: No old user can write data, the disks are not exposed and only the Backup can write. There is one issue: Some directories in my backup folders cannot be accessed even by the backup user. They have the right 0700 while other directories have 0777.The media folders do not seem to have that problem and seem to be consistently 0777. Questions: [*]How would you modify the above approach to safe-guard against accidental/malware modification of the files? [*]777 directories are not writeable by other users. This is as I wanted it, but doesn't the last "7" indicate that they should be? Limetech indicated in the article linked above that "SMB samba details: create mask = 770, directory mask = 770" [*]Even with a 0 (as in 700) the directories are visible by all users. What is the difference then between a 0 and a 4 (=read)? [*]Could it be that rights from the Windows source of the backed-up files/folders are carried over to unRAID? However, if so, I still don't understand as the rights under Windows are different than on the unRAID backup folder equivalents. E.g. one folder that has 0700 in unRAID (and cannot be accessed) seems to have the same security settings in Windows as a folder that can be accessed in unRAID (0777). [*]What can I do to set all files and folders to the correct settings so they are accessible? [*]What needs to be done to ensure that this continues to work in the future (rather than having to "patch" the files each time a backup is performed)? [*]Is it sufficient to set Export=No for the disks or is it required/recommended to set Security=Secure as well? [*]I haven't tried it yet but assume that a newly added disk would be added as Export=Yes, Security=Public so I will need to remember to lock it down with Export=No. Is there a way to change default for a disk? Thanks so much for your advice. Tom

Hi Since V5 I am struggling with the GUI stalling when i stop the array from the main menu. The messages either go into a loop around freeing the releasing the shares, as just now again, the webgui becomes unresponsive and gives a "This webpage is not available - ERR_NAME_NOT_RESOLVED". I have searched the forums and came accross the Kill open files plugin which doesn't always help and have installed the extended powerdown script which sometimes takes the array down, but the big button is still often the only resolve. This leaves the array with an unclean shutdown which I really want to avoid whenever possible. In all cases the GUI becomes unresponsive and cannot be used anymore. I am writing here because I suspect that the only real resolution is the change the "stop array" function in unRAID to check for any stop down hindrances and either inform the user what the problem is, stop the process and make the GUI responsive again attempt the resolution of the conflict ie. by offering to kill those processes individually just issue a warning that other processes are preventing stopping the array and proceed after a confirmation I must say that this is by far the biggest annoyance i have with unRAID at the moment and hope that you can have stab at it during one of the upcoming releases. Thanks, tazman

The BIOS log also does not reveal anything at the time of the boot. But I have a few single ECC failures. Not sure what the board does if there is a dual one.

I always suspected that cats got their name from cat-astrophe but none has been spotted inside here. But then you never know, they like to be out at night.

@dgaschk: the last mail sent 1.5 hours before the shutdown was a disk temperature warning for my Seagate cache disk reaching at 46C. This happens regularly. Nothing special. There were no emergency temp shutdown warnings. I get them when I e.g. rebuild parity and some drives hit 50C. I never reached an automatic shutdown temperature. At the time of the shutdown the server was idle, everybody was sleeping and the drive should have been spun-down. @RobJ: 1,2 3 and 5 don't seem to apply. No recent changes to the system. Everybody was sleeping. Re. 3. I checked my UPS and no power outage was logged there. Leaves 4. I checked with my kids and nobody claims to have done anything. The buttons are also not too easy to press. A command line "shutdown now" start with: May 29 10:00:41 SS shutdown[20176]: shutting down for system reboot May 29 10:00:43 SS init: Switching to runlevel: 6 May 29 10:00:50 SS rc.unRAID[20204][20205]: Powerdown V2.06 A press of the power button with: May 29 10:06:49 SS powerdown[10650]: Powerdown initiated May 29 10:06:49 SS powerdown[10654]: Powerdown V2.06 May 29 10:06:49 SS rc.unRAID[10656][10657]: Processing /etc/rc.d/rc.unRAID.d/ kill scripts. No beep. I am getting the dual beep with a normal GUI shutdown but then the logging starts with: May 29 10:15:33 SS emhttp: shcmd (69): /usr/local/sbin/emhttp_event stopping_svcs May 29 10:15:33 SS emhttp_event: stopping_svcs May 29 10:15:33 SS emhttp: Stop AVAHI... May 29 10:15:33 SS emhttp: shcmd (70): /etc/rc.d/rc.avahidaemon stop |& logger ... May 29 10:15:49 SS emhttp: shcmd (124): beep -r 2 May 29 10:15:50 SS emhttp: mdcmd: write: Invalid argument May 29 10:15:50 SS emhttp: Stop AVAHI... May 29 10:15:50 SS emhttp: shcmd (125): /etc/rc.d/rc.avahidaemon stop |& logger Still different from the log with the automatic shutdown

Hi, I need your help with something really strange. After years of stable operation the server did shutdown unexpectedly on its own recently. I could no find any obvious trigger in the log. This is the section of the log file where the shutdown begins (after line 2, to my best knowledge): May 25 05:59:37 SS emhttp: shcmd (225): /usr/sbin/hdparm -y /dev/sdb &> /dev/null May 25 06:26:53 SS emhttp: shcmd (226): beep -r 2 May 25 06:26:54 SS emhttp: shcmd (227): /usr/local/sbin/emhttp_event stopping_svcs May 25 06:26:54 SS emhttp_event: stopping_svcs May 25 06:26:54 SS kernel: mdcmd (122): nocheck May 25 06:26:54 SS kernel: md: nocheck_array: check not active May 25 06:26:54 SS emhttp: Stop AVAHI... May 25 06:26:54 SS emhttp: shcmd (228): /etc/rc.d/rc.avahidaemon stop |& logger May 25 06:26:54 SS logger: Stopping Avahi mDNS/DNS-SD Daemon: stopped The shutdown was completed by May 25 06:27:28 SS rc.unRAID[28349][28429]: Array Stopped I am attaching the full log file. The server is connected to an UPS but there was no power outage. I also did not receive any hard drive over-temp shutdown warnings. The only thing that has happened compared to before was that installed a few more fans in the case a few days before. This has not re-occurred since but I am nervous as I am about to replace my parity drive and don't want this to happen during the process. I am on 5.0.6. Does anybody have a hunch what is going on here? Thanks so much for your help! Thomas Log_1_-_syslog-20150525-062728.zip

Regarding the SAS2LP-MV8 support. I recently switched motherboards from a Supermicro X9SCL+-F to a X9SCM-F which resolved the problems with my three cards. There is a new Linux driver available at ftp://ftp.supermicro.com/driver/SAS/Marvell/MV8/SAS2/Driver/Linux/4.0.0.1534/. Tom: are you planning to integrate that into the next release? Is is resolving the problems you are still experiencing with those cards?

I have a very similar system to yours. Neither disabling ROM boot nor Int13 did resolve my problems with those cards. But changing the motherboard from Supermicro X9SCL+-F to X9SCM-F did. Do you have the link to the updated firmware? It is not referenced on the product page yet: http://www.supermicro.com/products/accessories/addon/AOC-SAS2LP-MV8.cfm There is an updated Linux driver there though. Wondering if that will improve anything.

Hi, I just noticed a folder/share called "+/-" for the first time. It contains data that should reside on a user share. I tried searching for it in the forum but "+/-" cannot be searched for. Does anybody know what this folder is for, how to deal with it, under which circumstances it is created and how avoid it? Thanks, Tom

@ stomp This is the link to the card http://www.supermicro.com/products/accessories/addon/AOC-SAS2LP-MV8.cfm If I remember the specs of the old card right it is: - 6GB (SATA3) vs 3GB (SATA2) - PCI-E 8x vs. 4x - Different Marvell chip (9480)

Thanks Johnm. I tried that and it does not make a difference.

I just completed an extensive memory test which was ok. The irqpoll and irqfix options did not fiex the "IRQ 16 disabled" message. In the meantime Supermicro has acknowledged the problem and is working with Marvell on a resolution. The boot stall with multiple cards is a know issue and the resolution is the disabling of the PCI adapter BIOS boots for all cards except the one with the boot drive on.

I have just built a system with three AOC-SAS2LP-MV8s and have serious issues with it on 5.13 and 5.14. However, I suspect a card problem as my WHS system with one card also has issues. On WHS writes fail within few seconds and the drive disappears from Windows. This only happens in 64-bit windows, not 32-bit. On unRAID multiple cards do not work well together. The system (see specs below) stalls when the card BIOS boots are enabled. The Marvell BIOS only recognises two cards and the boot halts at the second Marvell BIOS screen. This happens when: Two cards are installed in the two 8x slots and a hard drive is connected to ports 2-7 on the second card Three cards are installed and any hard disk is connected to Adapter 1 (as reported by the BIOS) So I disabled the adapters BIOS boots in the board BIOS. unRAID was able to boot and the three cards were recognized. However, Issue 1: When drives are connected to any adapter the following errors are logged: --------------------------------------------------------------------------------------------- Nov 23 19:16:42 SS kernel: ata7: sas eh calling libata port error handler (Errors) Nov 23 19:16:42 SS kernel: ata8: sas eh calling libata port error handler (Errors) Issue 2: IRQ 16 disabled ---------------------------- Most of the time I am also getting an IRQ 16 disabled error. If this happens the section below appear three times (one for each adapter?). The error occurs most of the time especially when drives are connected to adapter 0, ports 5, 1 ports 3-6 or 2, ports 2-7. The PCI report shows IRQ 16 is used by two cards (one uses IRQ 17). IRQ 16 also seems to create the slow write speeds to the drives (see next issue). Nov 23 18:28:56 SS kernel: sdc: sdc1 Nov 23 18:28:56 SS kernel: sd 8:0:0:0: [sdc] Attached SCSI disk Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1205:phy 0 attach dev info is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1207:phy 0 attach sas addr is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1205:phy 1 attach dev info is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1207:phy 1 attach sas addr is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1205:phy 2 attach dev info is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1207:phy 2 attach sas addr is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1205:phy 3 attach dev info is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1207:phy 3 attach sas addr is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1205:phy 4 attach dev info is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1207:phy 4 attach sas addr is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1205:phy 5 attach dev info is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1207:phy 5 attach sas addr is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1205:phy 6 attach dev info is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1207:phy 6 attach sas addr is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1205:phy 7 attach dev info is 0 Nov 23 18:28:56 SS kernel: drivers/scsi/mvsas/mv_sas.c 1207:phy 7 attach sas addr is 0 Nov 23 18:28:56 SS kernel: scsi9 : mvsas Nov 23 18:28:56 SS kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Nov 23 18:28:56 SS kernel: Pid: 0, comm: swapper Not tainted 3.1.0-unRAID #2 Nov 23 18:28:56 SS kernel: Call Trace: Nov 23 18:28:56 SS kernel: [<c104fa80>] __report_bad_irq+0x1f/0x95 Nov 23 18:28:56 SS kernel: [<c104fc2d>] note_interrupt+0x137/0x1a8 Nov 23 18:28:56 SS kernel: [<c104e76a>] handle_irq_event_percpu+0xef/0x100 Nov 23 18:28:56 SS kernel: [<c1050146>] ? handle_edge_irq+0xcb/0xcb Nov 23 18:28:56 SS kernel: [<c104e79f>] handle_irq_event+0x24/0x3b Nov 23 18:28:56 SS kernel: [<c1050146>] ? handle_edge_irq+0xcb/0xcb Nov 23 18:28:56 SS kernel: [<c10501af>] handle_fasteoi_irq+0x69/0x82 Nov 23 18:28:56 SS kernel: <IRQ> [<c1003566>] ? do_IRQ+0x37/0x90 Nov 23 18:28:56 SS kernel: [<c130bea9>] ? common_interrupt+0x29/0x30 Nov 23 18:28:56 SS kernel: [<c11dd951>] ? acpi_idle_enter_bm+0x22a/0x25e Nov 23 18:28:56 SS kernel: [<c1272de0>] ? cpuidle_idle_call+0x75/0xbd Nov 23 18:28:56 SS kernel: [<c1001a5f>] ? cpu_idle+0x39/0x5a Nov 23 18:28:56 SS kernel: [<c12fb578>] ? rest_init+0x58/0x5a Nov 23 18:28:56 SS kernel: [<c145172d>] ? start_kernel+0x28c/0x291 Nov 23 18:28:56 SS kernel: [<c14510b0>] ? i386_start_kernel+0xb0/0xb7 Nov 23 18:28:56 SS kernel: handlers: Nov 23 18:28:56 SS kernel: [<c12435ee>] usb_hcd_irq Nov 23 18:28:56 SS kernel: [<f84730c9>] mvs_interrupt Nov 23 18:28:56 SS kernel: [<f84730c9>] mvs_interrupt Nov 23 18:28:56 SS kernel: Disabling IRQ #16 Issues 3: Generally low write speeds and a few writes fail ----------------------------------------------------------------- Drives connected to Adapters 0 (the 4x slot) and 2 ports 2-7 are 1-3 Mb/s Drives connected to adapter 1 and 2 port 0+1 are about 50 Mb/s I am also getting 50 Mb/s with drives connected to the motherboard In a few cases the write did fail altogether. I always wrote directly to the drive. I thought the slow write speeds were related to the IRQ16 but in case of the adapater 1, 3+4 the IRQ16 error was present but write speeds were ok I haved tried changing various BIOS setting including PCI latency and PCI Gen1 force with out any difference. Supermicro has acknowledged the WHS issue and and is currently working with Marvell on a solution. The unRAID issues is reported but not yet acknowledged by Supermicro. Welcome any recommendations from the community on what else I could try to circumvent or better describe/isolate the problem. tazman

Hi, For my new build (see specs below) I was looking for a currently available USB stick. As the officially supported models were hard to get in Singapore. So I just wanted to share the models that I found work (ie. have an individual ID recognised by unRAID): USB Stick Avg read speed (MB/s) Access time (ms) Sony Micro Vault CLICK (4GB) 32.9 0.581 Sandisk Ultra (8GB) 32.9 0.729 No name 4GB* 18.7 1.32 * picture link is only an example, I got those as an event give away Due to the best performance I went with the Sony. Working well so far. tazman