March 1, 201511 yr Yes SMB is on - some more fiddling and I can see the difference. My (working) B12 has SMB in workgroup mode. As the new B14 key allows AD integration and I have a domain I was using SMB in domain mode - as soon as I use domain based SMB the tab and ability to turn off the disk based shares goes away. I have changed to workgroup SMB mode and the tab reappears.... I would really rather use domain based SMB though and disable the disk shares!
March 1, 201511 yr Yes SMB is on - some more fiddling and I can see the difference. My (working) B12 has SMB in workgroup mode. As the new B14 key allows AD integration and I have a domain I was using SMP in domain mode - as soon as I use domain based SMB the tab and ability to turn off the disk based shares goes away. I have changed to workgroup SMB mode and the tab reappears.... I would really rather use domain based SMb though and disable the disk shares! Sounds like you just found a bug. If you go to workgroup mode and turn off disk shares, then go back to AD mode, does that effectively work for now? Will report this issue up to Tom for resolution.
March 1, 201511 yr Was just trying that before you spoke - yes I can disable the shares in workgroup mode - then changed back to domain SMB and all works and the disk shares are still disabled - thanks! Yes looks like a bug.
March 1, 201511 yr Was just trying that before you spoke - yes I can disable the shares in workgroup mode - then changed back to domain SMB and all works and the disk shares are still disabled - thanks! Yes looks like a bug. Easy fix I think. Will report this to tom for review. Thanks for reporting!!
March 1, 201511 yr I am getting the following message in the system log, while my network gets locked up for about 5-7 seconds: Tower kernel: r8169 0000:04:00.0 eth0: link up I have Realtek RTL8111B LAN Controller on my MB. I remember this being an issue in v5 beta cycle where if I remember correctly the solotion was to move to disable the r8169 kernel driver and use r8168 driver from the vendor. I understood that recently we moved back to r8169. Is there anyone else experiencing this?
March 1, 201511 yr I upgraded to 6.0b14b from 6.0b9 this weekend. Largely went well, but a few things to report. 1. I have 2 disks mounted outside of the array - a 750G and a 500G. When the GUI is up, each of the two disks are routinely accessed (their disk lights blink every second or so) and I get the following message on the console repeating forever. They do not go to the syslog. Seemed to be timed with the blinking lights. SG_IO: bad/missing sense data, sb[0]: f0 00 05 00 00 00 00 0b 00 00 00 00 20 00 ... I saw some hits on this type message that didn't seem related to this issue. I think that somehow the GUI is confused by these non-array disks. If I bring down the GUI the blinking lights stop and so do the messages. 2. I started getting some serious issues in my syslog. I wanted to attach my syslog but looks like no attachments here. Below is the lead up and the first 100 lines or so from when they began, and I can post the syslog if that would be helpful. Note the crashes went on for 12,000 lines before I stopped the array and rebooted. Other than that looks pretty good. - mymain seems to work fine - I redid my Docker setup, making my SSD my cache, and creating a loopback device. Hooking back up to the appdata was easy. - The new Docker plugin is excellent - much matured from beta9 stage. - GUI looks super. Shame I have to keep it closed. - I did not notice any problems with disks spinning up or down, but didn't test it thoroughly. Here is the syslog snippet: Mar 1 13:12:49 Shark kernel: mdcmd (70): spinup 0 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (71): spinup 3 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (72): spinup 4 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (73): spinup 5 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (74): spinup 6 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (75): spinup 7 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (76): spinup 9 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (77): spinup 12 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (78): spinup 13 Mar 1 13:12:49 Shark kernel: Mar 1 13:12:49 Shark kernel: mdcmd (79): spinup 15 Mar 1 13:12:49 Shark kernel: Mar 1 13:15:40 Shark kernel: ffff88041e8433f0 0000000000000001 ffff88014cfee800 ffffea0000f0cfc0 Mar 1 13:15:40 Shark kernel: Call Trace: Mar 1 13:15:40 Shark kernel: [<ffffffff8136e67a>] ? timerqueue_add+0x7a/0x98 Mar 1 13:15:40 Shark kernel: [<ffffffff8107ccef>] ? enqueue_hrtimer+0x19/0x3d Mar 1 13:15:40 Shark kernel: [<ffffffff8107d251>] ? __hrtimer_start_range_ns+0x25d/0x26f Mar 1 13:15:40 Shark kernel: [<ffffffff815f9d91>] schedule+0x65/0x67 Mar 1 13:15:40 Shark kernel: [<ffffffff815fc331>] schedule_hrtimeout_range_clock+0xab/0xdb Mar 1 13:15:40 Shark kernel: [<ffffffff8107cda8>] ? hrtimer_get_res+0x41/0x41 Mar 1 13:15:40 Shark kernel: [<ffffffff815fc36f>] schedule_hrtimeout_range+0xe/0x10 Mar 1 13:15:40 Shark kernel: [<ffffffff81106555>] poll_schedule_timeout+0x3e/0x61 Mar 1 13:15:40 Shark kernel: [<ffffffff81107764>] do_sys_poll+0x3d7/0x479 Mar 1 13:15:40 Shark kernel: [<ffffffff810f39d7>] ? mem_cgroup_begin_page_stat+0x26/0x92 Mar 1 13:15:40 Shark kernel: [<ffffffff810d34f9>] ? page_add_file_rmap+0x34/0x5c Mar 1 13:15:40 Shark kernel: [<ffffffff810a9782>] ? unlock_page+0x1f/0x23 Mar 1 13:15:40 Shark kernel: [<ffffffff810a9d6e>] ? filemap_map_pages+0x152/0x1c7 Mar 1 13:15:40 Shark kernel: [<ffffffff8110666c>] ? poll_select_copy_remaining+0xf4/0xf4 Mar 1 13:15:40 Shark kernel: [<ffffffff8110666c>] ? poll_select_copy_remaining+0xf4/0xf4 Mar 1 13:15:40 Shark kernel: [<ffffffff810cbe1a>] ? handle_mm_fault+0x5e7/0xbda Mar 1 13:15:40 Shark kernel: [<ffffffff810fe219>] ? pipe_read+0x1c6/0x229 Mar 1 13:15:40 Shark kernel: [<ffffffff810f76fd>] ? new_sync_read+0x78/0x9c Mar 1 13:15:40 Shark kernel: [<ffffffff810496df>] ? recalc_sigpending+0x17/0x48 Mar 1 13:15:40 Shark kernel: [<ffffffff81011668>] ? read_tsc+0x9/0xd Mar 1 13:15:40 Shark kernel: [<ffffffff8107b99a>] ? timespec_add_safe+0x22/0x50 Mar 1 13:15:40 Shark kernel: [<ffffffff8110789e>] SyS_poll+0x4b/0xb4 Mar 1 13:15:40 Shark kernel: [<ffffffff815fd1a9>] system_call_fastpath+0x12/0x17 Mar 1 13:15:40 Shark kernel: cron S ffff88042fc91d00 0 23685 23681 0x00000000 Mar 1 13:15:40 Shark kernel: ffff8800082cfe68 0000000000000082 ffff8800082cffd8 ffff880415a0c890 Mar 1 13:15:40 Shark kernel: 0000000000011d00 ffff88041956d0a0 0000000000000000 ffff8801087c6000 Mar 1 13:15:40 Shark kernel: ffff8800082cfe78 ffffffff81103e15 0000000000000000 0000000000000065 Mar 1 13:15:40 Shark kernel: Call Trace: Mar 1 13:15:40 Shark kernel: [<ffffffff81103e15>] ? user_path_at_empty+0x60/0x90 Mar 1 13:15:40 Shark kernel: [<ffffffff8136e67a>] ? timerqueue_add+0x7a/0x98 Mar 1 13:15:40 Shark kernel: [<ffffffff8107ccef>] ? enqueue_hrtimer+0x19/0x3d Mar 1 13:15:40 Shark kernel: [<ffffffff8107d251>] ? __hrtimer_start_range_ns+0x25d/0x26f Mar 1 13:15:40 Shark kernel: [<ffffffff815f9d91>] schedule+0x65/0x67 Mar 1 13:15:40 Shark kernel: [<ffffffff815fc1b3>] do_nanosleep+0x82/0xf5 Mar 1 13:15:40 Shark kernel: [<ffffffff8107d9be>] hrtimer_nanosleep+0x8c/0x10e Mar 1 13:15:40 Shark kernel: [<ffffffff8107cda8>] ? hrtimer_get_res+0x41/0x41 Mar 1 13:15:40 Shark kernel: [<ffffffff8107da90>] SyS_nanosleep+0x50/0x60 Mar 1 13:15:40 Shark kernel: [<ffffffff815fd1a9>] system_call_fastpath+0x12/0x17 Mar 1 13:15:40 Shark kernel: sshd S ffff88042fd91d00 0 23686 23682 0x00000000 Mar 1 13:15:40 Shark kernel: ffff880008077928 0000000000000082 ffff880008077fd8 ffff8804167bd8b0 Mar 1 13:15:40 Shark kernel: 0000000000011d00 ffff88041956f0e0 0000000000000287 ffff8804191f39d8 Mar 1 13:15:40 Shark kernel: ffff880008077888 ffffffff813857db 0000000002000020 ffff880151926230 Mar 1 13:15:40 Shark kernel: Call Trace: Mar 1 13:15:40 Shark kernel: [<ffffffff813857db>] ? __percpu_counter_add+0x53/0x60 Mar 1 13:15:40 Shark kernel: [<ffffffff812c3195>] ? btrfs_mark_buffer_dirty+0xaf/0xb7 Mar 1 13:15:40 Shark kernel: [<ffffffff812dbaaf>] ? btrfs_get_token_32+0x79/0xc7 Mar 1 13:15:40 Shark kernel: [<ffffffff815f9d91>] schedule+0x65/0x67 Mar 1 13:15:40 Shark kernel: [<ffffffff815fc2bd>] schedule_hrtimeout_range_clock+0x37/0xdb Mar 1 13:15:40 Shark kernel: [<ffffffff8106b642>] ? add_wait_queue+0x3f/0x44 Mar 1 13:15:40 Shark kernel: [<ffffffff8110650e>] ? __pollwait+0xbf/0xc8 Mar 1 13:15:40 Shark kernel: [<ffffffff815fc36f>] schedule_hrtimeout_range+0xe/0x10 Mar 1 13:15:40 Shark kernel: [<ffffffff81106555>] poll_schedule_timeout+0x3e/0x61 Mar 1 13:15:40 Shark kernel: [<ffffffff81106e53>] do_select+0x5cf/0x610 Mar 1 13:15:40 Shark kernel: [<ffffffff812cb5b3>] ? btrfs_direct_IO+0x1ec/0x1ec Mar 1 13:15:40 Shark kernel: [<ffffffff8110666c>] ? poll_select_copy_remaining+0xf4/0xf4 Mar 1 13:15:40 Shark kernel: [<ffffffff812defe4>] ? free_extent_state+0x15/0x17 Mar 1 13:15:40 Shark kernel: [<ffffffff812df768>] ? __set_extent_bit+0x3af/0x3eb Mar 1 13:15:40 Shark kernel: [<ffffffff810af25c>] ? free_hot_cold_page_list+0x31/0x47 Mar 1 13:15:40 Shark kernel: [<ffffffff810b402c>] ? release_pages+0x1cf/0x23d Mar 1 13:15:40 Shark kernel: [<ffffffff8110702a>] core_sys_select+0x196/0x2a7 Mar 1 13:15:40 Shark kernel: [<ffffffff810cea78>] ? vma_rb_erase+0x189/0x1c6 Mar 1 13:15:40 Shark kernel: [<ffffffff810cfe7b>] ? do_munmap+0x2ca/0x2eb Mar 1 13:15:40 Shark kernel: [<ffffffff811071ba>] SyS_select+0x7f/0xb5 Mar 1 13:15:40 Shark kernel: [<ffffffff810cfee7>] ? vm_munmap+0x4b/0x5b Mar 1 13:15:40 Shark kernel: [<ffffffff815fd1a9>] system_call_fastpath+0x12/0x17 Mar 1 13:15:40 Shark kernel: syslog-ng S ffff88042fd51d00 0 23687 23683 0x00000000 Mar 1 13:15:40 Shark kernel: ffff8800083c7dd8 0000000000000086 ffff8800083c7fd8 ffff8803f31ad8b0 Mar 1 13:15:40 Shark kernel: 0000000000011d00 ffff88041956e8d0 ffff8800083c7d18 ffffffff810fb76a Mar 1 13:15:40 Shark kernel: ffff8800083c7d38 ffffffff812b4b47 0000000000000001 ffff880105f43800 Mar 1 13:15:40 Shark kernel: Call Trace: Mar 1 13:15:40 Shark kernel: [<ffffffff810fb76a>] ? inode_get_bytes+0x36/0x3e Mar 1 13:15:40 Shark kernel: [<ffffffff812b4b47>] ? btrfs_block_rsv_check+0x4e/0x60 Mar 1 13:15:40 Shark kernel: [<ffffffff8136e67a>] ? timerqueue_add+0x7a/0x98 Mar 1 13:15:40 Shark kernel: [<ffffffff8107ccef>] ? enqueue_hrtimer+0x19/0x3d Mar 1 13:15:40 Shark kernel: [<ffffffff8107d251>] ? __hrtimer_start_range_ns+0x25d/0x26f Mar 1 13:15:40 Shark kernel: [<ffffffff815f9d91>] schedule+0x65/0x67 Mar 1 13:15:40 Shark kernel: [<ffffffff815fc331>] schedule_hrtimeout_range_clock+0xab/0xdb Mar 1 13:15:40 Shark kernel: [<ffffffff8107cda8>] ? hrtimer_get_res+0x41/0x41 Mar 1 13:15:40 Shark kernel: [<ffffffff815fc36f>] schedule_hrtimeout_range+0xe/0x10 Mar 1 13:15:40 Shark kernel: [<ffffffff8112828e>] ep_poll+0x270/0x2ab Mar 1 13:15:40 Shark kernel: [<ffffffff8105e57d>] ? wake_up_process+0x36/0x36 Mar 1 13:15:40 Shark kernel: [<ffffffff81129006>] SyS_epoll_wait+0x88/0xb8 Mar 1 13:15:40 Shark kernel: [<ffffffff815fd1a9>] system_call_fastpath+0x12/0x17 Mar 1 13:15:40 Shark kernel: sabnzbdplus S ffff88042fdd1d00 0 23688 23684 0x00000000 Mar 1 13:15:40 Shark kernel: ffff880012b03928 0000000000000086 ffff880012b03fd8 ffff880008d3c080 Mar 1 13:15:40 Shark kernel: 0000000000011d00 ffff8804195d0000 ffff880012b03888 ffffffff81065c7d Mar 1 13:15:40 Shark kernel: 0000000000000000 ffff880012b03a70 ffff880012b03888 ffffffff81367cce
March 1, 201511 yr Any unassigned disks go into the array 'devs' which is maintained by emhttp. The GUI by default polls emhttp in real-time, meaning every 3-5 seconds. You can disable this behavior by changing the "Page update frequency" to disabled (see settingss -> display settings) and see if that makes a difference.
March 1, 201511 yr Any unassigned disks go into the array 'devs' which is maintained by emhttp. The GUI by default polls emhttp in real-time, meaning every 3-5 seconds. You can disable this behavior by changing the "Page update frequency" to disabled (see settingss -> display settings) and see if that makes a difference. Yep - that stops the continuous messages. But every browser refresh of the WebGui generates one. So this is a temporary workaround, not a fix.
March 1, 201511 yr The new drive spin state logic doesn't detect when drives are spun up due actions performed on the command line. What are you doing? It works for me. I can spin down all of my drives, start my script to update md5's which walks through all the drives one at a time (not user shares), and dashboard / main properly reflect the drive currently in use. Running a new version of my disk speed utility which does a sync & dd. The GUI was always stating the drives were spun down even though I was running my script multiple times. Though now when I try to reproduce it, it's working fine on two systems. *shrug*
March 1, 201511 yr Ok - slight annoyance ... Whenever you update a web form, like the display settings, and change a setting, a transparent overlay appears telling you that there are uncommitted changes on the form. But the overlay blocks the appy button, so you have to wait or click elsewhere in an attempt to get the overlay to clear before the button can be clicked. If the form were a little bit longer, leaving space for the overlay under the buttons that might fix this.
March 1, 201511 yr Ok - slight annoyance ... Whenever you update a web form, like the display settings, and change a setting, a transparent overlay appears telling you that there are uncommitted changes on the form. But the overlay blocks the appy button, so you have to wait or click elsewhere in an attempt to get the overlay to clear before the button can be clicked. If the form were a little bit longer, leaving space for the overlay under the buttons that might fix this. I notice this! I use it as an excuse to check the change I am about to make
March 1, 201511 yr Any unassigned disks go into the array 'devs' which is maintained by emhttp. The GUI by default polls emhttp in real-time, meaning every 3-5 seconds. You can disable this behavior by changing the "Page update frequency" to disabled (see settingss -> display settings) and see if that makes a difference. Yep - that stops the continuous messages. But every browser refresh of the WebGui generates one. So this is a temporary workaround, not a fix. Need help of LT to look into this, something internally in emhttp.
March 1, 201511 yr Ok - slight annoyance ... Whenever you update a web form, like the display settings, and change a setting, a transparent overlay appears telling you that there are uncommitted changes on the form. But the overlay blocks the appy button, so you have to wait or click elsewhere in an attempt to get the overlay to clear before the button can be clicked. If the form were a little bit longer, leaving space for the overlay under the buttons that might fix this. In the upcoming version this behavior has been changed (for the better I hope) ...
March 1, 201511 yr Also, it is possible to disable uncommited changes warnings. See settings -> Confirmations.
March 1, 201511 yr Another minor annoyance. Is it really necessary to store the ssmtp.conf file in the root of the Flash Drive? (It contains the e-mail server password in plain English. It would be so much nicer to have it buried a bit deeper in the file structure where the casual browser would not immediately see it! It stands out like a sore thumb there. )
March 1, 201511 yr Another minor annoyance. Is it really necessary to store the ssmtp.conf file in the root of the Flash Drive? (It contains the e-mail server password in plain English. It would be so much nicer to have it buried a bit deeper in the file structure where the casual browser would not immediately see it! It stands out like a sore thumb there. ) This file should only live in /etc/ssmtp (RAM), not sure why it ended up in the root of your flash ... (can be safely deleted)
March 1, 201511 yr Any unassigned disks go into the array 'devs' which is maintained by emhttp. The GUI by default polls emhttp in real-time, meaning every 3-5 seconds. You can disable this behavior by changing the "Page update frequency" to disabled (see settingss -> display settings) and see if that makes a difference. Yep - that stops the continuous messages. But every browser refresh of the WebGui generates one. So this is a temporary workaround, not a fix. Need help of LT to look into this, something internally in emhttp. Maybe you can give some more info about your setup/situation, when I put disks outside the array I can't reproduce the error.
March 1, 201511 yr Another minor annoyance. Is it really necessary to store the ssmtp.conf file in the root of the Flash Drive? (It contains the e-mail server password in plain English. It would be so much nicer to have it buried a bit deeper in the file structure where the casual browser would not immediately see it! It stands out like a sore thumb there. ) This file should only live in /etc/ssmtp (RAM), not sure why it ended up in the root of your flash ... (can be safely deleted) Thank you. I am not sure how it got there either... Perhaps some time during the beta process as I was one of those who started with beta 1 on the test bed.
March 2, 201511 yr Maybe you can give some more info about your setup/situation, when I put disks outside the array I can't reproduce the error. It may not be Dynamix fault. I now believe the issue is caused by the ARC-1200 controller. It is housing a RAID0 parity pair. I get the same error when I run the command ... root@Shark:/boot# hdparm -C /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: f0 00 05 00 00 00 00 0b 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: standby Don't think it is hurting anything. It is just the constant pinging of emhttp/Dynamix that caused it to become visible.
March 2, 201511 yr Also, it is possible to disable uncommited changes warnings. See settings -> Confirmations. That's handy to know. One other thing I would like to see is within the docker containers advanced settings it'd be nice to see what command is being run when you start. I know that technically all the information is there, but I think it would be a nice feature.
March 2, 201511 yr Also, it is possible to disable uncommited changes warnings. See settings -> Confirmations. That's handy to know. One other thing I would like to see is within the docker containers advanced settings it'd be nice to see what command is being run when you start. I know that technically all the information is there, but I think it would be a nice feature. Like a preview of the command based on the settings specified?
March 2, 201511 yr Scheduler started my beginning of the month parity check nicely but the message seems a little off... Event: unRAID Parity check Subject: Notice [] - Parity check started Description: No parity disk present Importance: warning I have a parity disk and is green etc. Not sure why it says that?
March 2, 201511 yr Like a preview of the command based on the settings specified? Yes, exactly that, why does it always seem like I can't get across what I mean in a succint and clear way! My brain is clearly fried!!
March 2, 201511 yr Also, it is possible to disable uncommited changes warnings. See settings -> Confirmations. That's handy to know. One other thing I would like to see is within the docker containers advanced settings it'd be nice to see what command is being run when you start. I know that technically all the information is there, but I think it would be a nice feature. Thank you!
March 2, 201511 yr Also, it is possible to disable uncommited changes warnings. See settings -> Confirmations. That's handy to know. One other thing I would like to see is within the docker containers advanced settings it'd be nice to see what command is being run when you start. I know that technically all the information is there, but I think it would be a nice feature. Thank you! Pretty sure its bonienl you want to thank rather than me..
Archived
This topic is now archived and is closed to further replies.