BoHiCa

Members
  • Posts

    18
  • Joined

  • Last visited

Everything posted by BoHiCa

  1. +1 would be great to be able to rebalance the panels between the 3 available columns. If this is editable in a config file somewhere, that's fine too. Lots of unnecessary scrolling, lol.
  2. Also hate to pile on to the resurrection of an ancient thread, but this one bit me today also and here's the solution for at least the SMT1500C line from APC. APC UPS Model: Smart-UPS SMT1500C (USA) The solution: 1. Update the Firmware on the UPS. You have to ensure that the firmware is updated to the latest so that MODBUS will work. This can be tricky, and you can *brick* your UPS, and, bonus, APC has models that look exactly the same, I mean exactly the same, that even APC has been unable to reliably determine which variant you have from your serial#. Total faceplant by APC, very uncharacteristic of them as a company. Anyway, it is what it is. If you have the same model as this (SMT1500C) and the UPS is online and registered, it will "phone home" to the mothership and download any firmware updates to the UPS itself (assuming it is allowed out to the internet). You'll get a notification that a firmware update is available on the front panel of the UPS. Use the front-panel, navigate through the menus to apply the update (there's a *bunch* of redundant "Ok" you have to select since it is making sure you really want to do this w/o a secondary power supply for the unit... so don't do this during bad weather, etc. lol). The buttons on the LCD panel are a bit obtuse, but not too bad: Hit the "enter" key symbol (⏎) to select options and settings so it "sticks". Hit the "Esc" key (top left) to back out of the sub-menus. It takes about 10 minutes to verify and apply the firmware update. The UPS does not reboot, so you can leave things on and connected during this process, but, I do not recommend it! Best practice is to do this on a fully unloaded UPS just connected to the internet and utility power. Once it is completed you can proceed to step 2. I did all of this w/o the UPS being hooked to anything but the DMZ and utility power to let it phone home. 2. Once the latest firmware has been applied, navigate the menus and enable the "Advanced" view. This is required to enable the MODBUS support on the UPS (it is disabled by default for some reason...). 3. Navigate the menus to find the MODBUS support under "Configuration" (may be different text depending on the firmware version). The menu system is *clunky*. You use the "enter" (⏎) button (lower left on the series of 4 buttons on the LCD display) to select the option you want to change, then you use the up and down buttons on the right-hand side of the series of 4 buttons on the LCD display) to set it to "On", then hit the "enter" key symbol (⏎) so it "sticks". Hit the "Esc" key (top left) to back out to the main menu on the UPS again. That should do it. 4. Connect the USB cable to USB port on the SMT1500C UPS itself. This model has three connection ports: USB | RJ45 SERIAL | RJ45 ETHERNET on the back. You have to use the USB port on the back of the UPS, not the usual RJ45 -> USB cable that APC has used for decades. You'll be going from the USB port on the back of the UPS to a USB port on the Unraid server (i was using USB 2.0 ports). 5. Configure the Unraid settings: Navigate to the Settings tab on the Unraid web UIX, click the "UPS Settings" applet on the top row of icons, in the "System Settings" panel to get to the apcupsd config options. Set these values: Start APC UPS Daemon: Yes (duh) UPS Cable: USB Custom UPS Cable: {leave blank/empty} UPS Type: Modbus Device: {leave blank/empty} Other settings are dealer's choice. Click [Apply] and a few seconds later, you should be set. Proceed until captured!
  3. Good evening everyone! Loooooooonnngg time unraid user (10 years?), currently on 6.10.3 after uneventful updates from prior releases (6.10.2) about a week ago. Current uptime in the log is over 7 days. I first noticed these entries about 10 days ago, prior to 6.10.3 update being applied, hoped 6.10.3 would address this... It's good to have a dream! Jun 28 00:51:28 MAXTOWER nginx: 2022/06/28 00:51:28 [error] 5362#5362: *5697534 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/update2?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:28 MAXTOWER nginx: 2022/06/28 00:51:28 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /update2 Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: shpool alloc failed Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 612. Increase nchan_max_reserved_memory. Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: *5697535 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /cpuload Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: shpool alloc failed Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 934. Increase nchan_max_reserved_memory. Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: *5697538 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/update3?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /update3 Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: shpool alloc failed Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 503. Increase nchan_max_reserved_memory. Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: *5697539 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:29 MAXTOWER nginx: 2022/06/28 00:51:29 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /devices Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: shpool alloc failed Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 612. Increase nchan_max_reserved_memory. Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: *5697541 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /cpuload Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: shpool alloc failed Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 521. Increase nchan_max_reserved_memory. Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: *5697542 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/diskload?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /diskload Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: shpool alloc failed Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 902. Increase nchan_max_reserved_memory. Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: *5697548 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/update3?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /update3 Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: shpool alloc failed Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 503. Increase nchan_max_reserved_memory. Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: *5697549 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:30 MAXTOWER nginx: 2022/06/28 00:51:30 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /devices Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: shpool alloc failed Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 612. Increase nchan_max_reserved_memory. Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: *5697551 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /cpuload Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: shpool alloc failed Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 933. Increase nchan_max_reserved_memory. Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: *5697555 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/update3?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /update3 Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: shpool alloc failed Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 278. Increase nchan_max_reserved_memory. Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: *5697556 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/update1?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /update1 Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: shpool alloc failed Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 503. Increase nchan_max_reserved_memory. Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: *5697557 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:31 MAXTOWER nginx: 2022/06/28 00:51:31 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /devices Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: shpool alloc failed Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 613. Increase nchan_max_reserved_memory. Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: *5697559 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /cpuload Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: shpool alloc failed Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 521. Increase nchan_max_reserved_memory. Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: *5697560 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/diskload?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /diskload Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: shpool alloc failed Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 934. Increase nchan_max_reserved_memory. Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: *5697566 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/update3?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /update3 Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: shpool alloc failed Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 470. Increase nchan_max_reserved_memory. Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: *5697567 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/apcups?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /apcups Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [crit] 5362#5362: ngx_slab_alloc() failed: no memory Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: shpool alloc failed Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: nchan: Out of shared memory while allocating message of size 503. Increase nchan_max_reserved_memory. Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: *5697568 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" Jun 28 00:51:32 MAXTOWER nginx: 2022/06/28 00:51:32 [error] 5362#5362: MEMSTORE:00: can't create shared message for channel /devices First guess (about 10 days ago) was some type of DRAM error, but a full 72 hour burn-in with MemTest passed (about a week ago) with no errors, reducing suspicion of a hardware error. I did not notice anything else untoward (I wasn't using the box when these were logged however). I found these errors again when checking the logs (via the UI) trying to track down why the drop-count on my main NIC is steadily increasing (no errors, just drops). (Will address that in a separate thread, just looking for any hints on the nginix errors here). I have been leaving the UI (on the main "Dashboard") tab for the past few days while I have been attempting to track down the reason for the ethernet drops being reported, which is a change in the usual usage (it's headless and just does it's thing, only rarely needing to be checked in on for updates etc.) Shorter version: I do not normally leave the web UI loaded up and idling. Chrome (on Windows 10) Version 102.0.5005.115 (Official Build) (64-bit) (Chrome started an update cycle when I went to grab the version info). However, there are *numerous* reports in this thread of this occurring w/o any open browser tabs to the unraid UI. Reading this entire thread, the issue appears to have been present through several releases going back to 6.8.3 (2019) and other releases through, now 2022 (a few new posts today) at least. Another correlate seems to be using the web terminals to access unraid: I have not done this in many months, across several restarts now, so for this report, that aspect is likely not in play. The other suggestion was problematic dockers. I am only running the official Emby docker, with two variants (not active). All are current versions and appear to be working fine. I have one VM (Debian Jessie) that has not been up for months (only need it rarely). Lastly, I have not observed the log partition ever filling up (so far). All drives (including the flash) appear to have plenty of space left. Seems like this one may be an actual memory leak in the daemon <facepalm>... I hate tracking those down! Let me know if there's any more info you need! Thanks for taking a look. maxtower-diagnositcs-20220628-1758.zip
  4. If the problematic drive (and replacement) are Intel 320 series, be warned. I was rudely reminded of this one earlier this week. Google "Intel 8MB Bug" for a refresher. Intel pooped the bed on this one! Best consensus advice is if you have any of the Intel 320 series SSDs (any size) in use, *immediately* back them up and take them out of service. Apparently even the firmware fix doesn't resolve the problem. Reminds me of the 20 GiB Seagate bricks from the late 1990's.
  5. It was definitely a change to the format of the line-data in ./config/parity-checks.log Feb 26 18:09:40|76178|26.3 MB/s|0 Mar 5 18:09:14|76152|26.3 MB/s|0 Mar 12 19:09:49|76188|26.3 MB/s|0 2017 Mar 19 23:18:21|94700|21.1 MB/s|0|0 The first 3 lines are from 6.1.9, and the last is from 6.3.2. I took a bit of a haircut on the parity check speed with the version bump! Zoinks! My PCIe bus is saturated with so many drives on the under-powered motherboard (It's one of the Intel Atom boards), so that's likely the fastest it will get until I can migrate to better hardware with more individual lanes for each SATA device. Mystery solved!
  6. By all appearances the parity check ran through to completion, I did not interrupt it as far as I know. The box was idle and all drives spun-down prior to applying the update the day after the last parity check. The 6.1.9 UI showed the expected message. <shrug> The format of the log entries appears to be the same too. It will parity check again on Sunday. I'll keep an eye on it and go from there, lol. Thanks for your reply!
  7. I just ran through a successful upgrade from a very stable 6.1.9 version to 6.3.2 via the "Plugin" update method. Smooth as silk! This machine has no dockers currently configured (but dockers are enabled) nor VM's (hardware can't handle it, CPU is an Atom quad-core, 4 GiB RAM, 19 devices in the array, single parity drive (actually a hardware RAID 1 in an enclosure off an eSATA port = parity drive) and bonded ethernet for fault-tolerance. The drives are mostly re-purposed laptop drives for power consumption reduction).). System logs look clean (as in no errors), and all shares appear to be present and functioning nominally when accessed from Win 10 machines and Linux machines. The only "oddity" I've noticed is with the report of the last parity check in the Main tab and the Dashboard tab. I checked this right before performing the upgrade, and it reported 0 errors from the prior parity check which completed yesterday. Right after coming up in 6.3.2 and starting the array the UI reports this: Last checked on Sun 12 Mar 2017 07:09:49 PM CDT (yesterday), finding errors. Duration: 21 hours, 9 minutes, 48 seconds. Average speed: 26.3 MB/s That is the usual parity check time and speeds for this tiny box (motherboard SATA (6 drives) + eSATA (parity) and LSI HBA SATA controller on PCIe X8 (12 drives) + 4 cache SSD's on the LSI controller also), it varies by minutes +/- every week like clockwork. Data = xfs, cache = btrfs. I checked the /config/parity-checks.log file and the last entry from the last parity check is: Mar 12 19:09:49|76188|26.3 MB/s|0 I'm assuming that there have been some changes to the format of the entries in parity-checks.log that explain the odd phrasing in the UI, but wanted to make sure before I rely on the integrity of the box again. Great work guys!
  8. Then why bother speculating? Not much else to do until I finish looking up the skirt! In this case, I didn't think there would be any harm in posing the question with a clearly speculative answer Perhaps best to remain silent and thought a fool than to speak and remove all doubt. I get it. Just trying to put paths to follow out there is all. Won't do it again. In unRaid-6 the 'max server protocol' is set to SMB3 in smb.conf. You can check the smb.conf man page to find out what that means. Thanks for the RTFM tip! While I was trying to find where on unRAID the smb.conf file lives, I did exactly that. All the signal still points to potential pitfalls when dealing with SMB 3.1 clients as the Samba 4.x series currently supports only SMB 3.0 at maximum. It appears the the interop issues should be minimal and solvable with either and/or client and server side configuration tweaks tho!
  9. Per the Samba wiki (no way to gauge accuracy: https://wiki.samba.org/index.php/Samba3/SMB2), the 4.1.x series supports SMB 3.0. Per MSFT: Win 8.x supports 3.02 and Win 10 supports 3.10. Per the Samba wiki also: Samba server can not currently negotiate SMB3.02 as it does not have support for the new READ/WRITE flags (and the RDMA and Witness protocol improvements for SMB3.02 are not possible until the corresponding prerequisite optional SMB3.0 features that they are based on are added) Since Win10 is SMB 3.1, I'd bet on some iinteroperability issues. They're probably tunable too. Patience, and perseverance!
  10. I'm suspecting a user account level issue. I think if the equivalent of the "Everyone" account (public) has full control of any given 'user' share on unRAID things are fine, but outside of that, I'm betting with the newer SMB 3.1 (which is a *huge* improvement over prior versions, especially between other 3.1 SMB clients on the same subnet. e.g. no longer do files moved/copied from 'share a on server a' to 'share b on server b' when initiated from a 3rd machine (client c) have to traverse the triangle. SMB 3.1 file servers can 'figure it out' and the move/copy is executed directly from server-a to server-b without having to move the data through client-c.) that things go sideways. Should be able to test sometime next week.
  11. Interesting... Will have to set up a Win10 client and see what's up... Thanks for the ack-back!
  12. Windows 10 (RTM) "speaks" SMB v3.10, which likely doesn't play nice, by default, with older SMB protocols. I am not sure which dialect of SMB the version of Samba on unRAID v6 speaks. My total guess is it is SMB 2 at best, but very likely SMB v1. The below link may not seem related, but we have found it necessary to fix a multitude of network share mapping issues with Winblowz 2008 R2 and above and older CIFS/SMB file sharing devices: https://support.microsoft.com/en-us/kb/2686098 This *administrator* powershell script has always resolved the problems (Note: Not tested with Winblowz 10!): Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters” RequireSecureNegotiate -Value 0 -Force The solution discussed in the thread you linked likely will work as well. I think the PowerShell script above accomplishes the same thing, but doesn't involve manually mucking around in the registry The joy and pain of the bleeding edge! Good luck! Let us know if it works! [edit]Weird artifact in scriptlet when copy-pasted from Linux,,,fixed now..[/edit]
  13. I recently experienced a similar problem with a machine acting like it was possessed by a demented circus monkey. The problem was bad capacitors on the motherboard. One had even "erupted" like a volcano. You can often tell if a capacitor has gone rogue by simply looking at them. (Sometimes they smell too!) Capacitors look like little cans (sometimes bare aluminum in color, sometimes plastic wrapped various colors) but they almost always look like little cans soldered to the printed circuit board (pcb, mainboard). You can visually inspect them as they very often will show signs of bulging or leaking. The full-metal capacitors usually (modern ones anyway) have stress etching on the top to keep them from literally exploding and this will be bulged out on the tops of the cans. There was a series of bad capacitors that appeared in a lot of low and middle-tier boards from the early 2000's, but I still see failed capacitors on boards from the mid 2000's also. To reduce the risk somewhat, look for "Japanese" capacitors on the specs of any boards or components you buy. There are capacitors on controller cards, video cards, and in power-supplies too, not just main boards. Even solid state doesn't always last forever!
  14. This is a local DNS thing, and ken-ji says. Your ISP's DNS won't help you with this one. If you have a local DNS server for your LAN (e.g. local Active Directory or other DNS provider for your local networks), you can add a static entry there (your ASUS router might have DNSMasq running (a dns proxy provider for your local network), so you can add a static dns entry for your unRAID box). You can also try adding an entry to the local machine's 'hosts' file (varies by OS). For winblowz NT/2K/XP/7/8.x (probably 10 also): 1. Run notepad or Notepad++ as administrator (right click the exe and choose run-as Administrator) 2. Edit %SystemRoot%/System32/drivers/etc/hosts (For a typical winblowz client this is: C:\Windows\System32\drivers\etc\hosts) 3. There should be some extensive comments on how to add an entry in the file, but here's a typical entry: 192.168.1.199 Tower #unRAID Server 4. Save the file 5. *BAM!* page should load instantly if the web server is awake. The process above will be very similar depending on your client workstation OS (don't have any iPads or other Apple products to use as alternative examples, which I think have to be jailbroken to add manual entries anyway...). There are so many devices on home networks now, I they would all benefit from a local DNS master service somewhere (I run mine on my SmoothWall Express 3.1 router) to help keep track of things. Just make sure that the client machines first DNS entry is to your local DNS service provider (very often in home networks this is your router or whatever device is providing dhcp and/or gateway services), usually with forwarding of failed look-ups down-stream to your ISP or google's public DNS! It has gotten *insane* in the past decade or so! Hope that helps!
  15. Do you use the SanDisk Ultra Fit or the SanDisk Cruzer Fit? Ultra Fit: http://www.amazon.com/SanDisk-Ultra-Low-Profile-Flash-SDCZ43-032G-G46/dp/B00LLER2CS/ref=sr_1_2?ie=UTF8&qid=1436624467&sr=8-2&keywords=sandisk+ultra+fit Cruzer Fit: http://www.amazon.com/SanDisk-Cruzer-Low-Profile-Drive--SDCZ33-008G-B35/dp/B005FYNSUA/ref=sr_1_7?ie=UTF8&qid=1436624570&sr=8-7&keywords=sandisk++fit The Cruzer Fit series has been nothing but mint with unRAID boxes so far.
  16. For what it is worth, I was using Chrome (latest) from a Win 7 box when the hang/freeze happend in my scenario. *BUT* just prior to the hang I had in Chrome, I was trying to access the UI from the IE (cousin of IE 10) that is on Xbox One... Too many variables so far.
  17. Thanks for the nudges guys. I loaded up the 'powerdown' plugin per the instructions in this thread: http://lime-technology.com/forum/index.php?topic=31735.msg288775#msg288775 @BRiT: Is that the plugin thread you were referring to? (I was looking at another thread with a 2008 date, which had me thinking it wouldn't be current for v6: http://lime-technology.com/forum/index.php?topic=812.msg11124#msg11124). turl's forum search tips located the newer one pronto! @trurl: Thanks for the forum search methods. Indeed it isn't obvious that the search is tied to the current forum/sub-fourm level! Is there a safe way to kill and restart the web UI via ssh or console so a reboot isn't necessary if/when the UI hangs again?
  18. Good afternoon fellow unRAIDer's! I have also experienced the hung-UI and forced ungraceful reboot from command line to restore operation. shutdown now -r ver: 6.0.1 Plugins: (all up-to-date as of this post) 1. Preclear Disks 2. Dynamix System Temperatures (which also requires PERL initially) 3. Dynamix System Statistics 4. Nerd Tools 5. Dynamix webGUI (stock) 6. unRAID Server OS Docker enabled: 1. Plex Server (lime-tech repo) (up-to-date) VM's not enabled yet. Cache Pool: 4x 500 GiB Samsung_EVO Correlated activity at time of hang: I had just wrapped up a StorageCraft Shadow Protect back-up of a workstation to an SMB share that uses cache on the unRAID server. There were 6 files ~500 GiB in the cache after the back-up. I am trying to set up scheduled mover timing and parity checks, so I manually initiated a "Move Now" via the web UI to determine how long it would take to move the ~500 GiB from the cache to the array. Everything seemed to be progressing normally, and it appeared that the mover had just wrapped up sending the last, and largest file (~300 GiB) to the array when the UI hung. Partial log below, I was just watching the logger entries via the "Log" window available from the UI. Jul 4 21:23:31 MiniTower logger: ./SHADOW/WIN7U64/BCK/C_VOL-b042.spf Jul 4 21:23:31 MiniTower logger: .d..t...... ./ Jul 4 21:23:31 MiniTower logger: .d..t...... SHADOW/ Jul 4 21:23:31 MiniTower logger: .d..t...... SHADOW/WIN7U64/ Jul 4 21:23:31 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/ Jul 4 21:23:31 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/C_VOL-b042.spf Jul 4 22:12:19 MiniTower logger: ./SHADOW/WIN7U64/BCK/C_VOL-b042.md5 Jul 4 22:12:19 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/ Jul 4 22:12:19 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/C_VOL-b042.md5 Jul 4 22:12:20 MiniTower logger: ./SHADOW/WIN7U64/BCK/D_VOL-b042.spf Jul 4 22:12:20 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/ Jul 4 22:12:20 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/D_VOL-b042.spf Jul 4 22:12:54 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 Jul 4 22:19:22 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 Jul 4 22:46:42 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 Jul 4 22:52:08 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 Jul 4 23:03:55 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 Jul 4 23:23:21 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 Jul 4 23:24:06 MiniTower logger: ./SHADOW/WIN7U64/BCK/D_VOL-b042.md5 Jul 4 23:24:06 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/ Jul 4 23:24:06 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/D_VOL-b042.md5 Jul 4 23:24:11 MiniTower logger: ./SHADOW/WIN7U64/BCK/I_VOL-b042.spf Jul 4 23:24:11 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/ Jul 4 23:24:11 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/I_VOL-b042.spf Jul 4 23:50:02 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 Jul 5 00:24:52 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 Jul 5 01:01:51 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1 The last log entry posted back to the UI is listed above. Sorry I didn't grab the full log as I was only tracking the mover times and didn't expect a UI hang. Probable red-herring: Just before the hang in the UI (~10 mins before) I was attempting to connect to the webUI from an Xbone (Xbox One) browser session to attempt to access the Plex server via that method. The UI "mostly worked" in the version of IE on Xbone, but there were some strange artifacts, and I could not access the Docker UI via this method. I then went back to a Debian (Wheezy) workstation to get the Plex server's URL to try a direct connection. This occurred right as the webUI hung up. Too many variables, I know. I think the webUI hang is most likely related to the mover operation however, because of the timing. Too much correlation there to ignore. Unfortunately, I did not find the instructions for running a diagnostic nor checking for hung processes until I had rebooted the box, so I don't have that info to post up at this time. If this happens again, I will certainly grab the hung diagnostic at that time. The ssh session, all shares, and the docker (only have Plex set up) on the unRAID box was fine during the UI hang. The hang appeared to be limited to the web UI. Per other threads that mentioned just "waiting it out", I disconnected the web-UI session and let is stew over-night (~10 hours). It was still hung-up before I initiated the shutdown via the command line (~10 hours after the initial hang). No SMART errors on any of the 18 array disks, parity re-check still in-progress. Sure wish I had found this thread first! This brings me to the actual question that started the forum search to begin with: 1. What is the best way to perform a clean shutdown and reboot via the command line? I would like to avoid unnecessary parity checks (which take 36 hours on my box) if possible. I see references to a "powerdown" plugin but every thread that I found (except for this one) that mentions that plugin is from ~2008 - 2009 and does not appear to apply to version 6.x (at least not directly). I did use the powerdown plugin on my old 5.x unRAID box. Is there a link to the plugin for version 6.x that I just missed with my forum and google foo? If someone has a link to the current powerdown plugin that is compatible with version 6.x, a nudge in the right direction would be *greatly* appreciated! This looks to be a *tremendous* upgrade with astounding potential! Just need a way to restart the UI from the command line, and/or execute a clean shutdown and reboot to bring it back up! Thanks for your time and efforts on out behalf!