Jump to content

MrLeek

Members
  • Content Count

    109
  • Joined

  • Last visited

Community Reputation

4 Neutral

About MrLeek

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah thanks Squid. It's giving me the opportunity to review/consider how SMB is getting used on my server - one of my side projects is to better enable stored music instead of relying on an SMB mount. Virtually everything else is being handled by dockers...
  2. Checking some stuff this evening and I noticed that the ransomware plugin had tripped, turning off SMB in the process. Fuller details below: There's a slight confusion with the timestamps. Either this happened at 0849 UTC (in which case I was in work and my iMac was in hibernation) or 0749 UTC (when I was using my iMac for a few mins before going to work). Based on looking at the log data I've just saved off I believe it's the former timestamps Only machines switched on was an iMac and a MacBook. Scans haven't found anything on the iMac (and I'll be scanning the MacBook in a moment). There are (well, there were) three Windows-based VMs on the server. They were all powered off at the time (and had been for several days - they only get used in a lab environment). They've all been deleted for safety and can be rebuild from scratch when I next need them. All shares require a username/password to gain write access. The flash drive itself has no write permissions enabled I'm beginning to think this could be a false positive.....but since I'm in no rush to assume that's the case I'd though I'd ask the community for any thoughts/areas to investigate.
  3. Thanks both. The problem was indeed linked to that IP address allocation - something triggered the DHCP server to reallocate the IP address dynamically whilst I was trying to configure it to be a static address on the server. The result was a slight paradox! Forced power down then reboot with keyboard/monitor connected and it started right back up....and promptly obtained the IP address that it was configured to have. I've now issued the same IP in the router and all seems to be well.
  4. Been doing the final tweaks to my new server build....and I've turned off telnet in the GUI. I've then set the dynamically assigned address to be static in the GUI - and that's where things have gone astray. No access to the GUI via it's IP address or using tower.local. SSH times out. Telenet times out. Pings don't get answered. The array is stopped - done before I started making some final adjustments to build (so that's one good piece of news). So in theory I could power down, attach a video cable/keyboard and reboot it into GUI mode. But not sure if there's other things to try first. Edit: Almost certain I've done a derp by trying to statically configure the IP address it was using (10.0.1.4) - and this address worked when it was assigned dynamically....but arp -a from my iMac suggests that an Amazon device (Kindle more than likely) seems to be now linked to 10.0.1.4
  5. Finally got to this - new build is just about done and ready to go live. The Current Pending Sector count increase is new - I don't think it's a showstopper, but it doesn't bode well for a server drive. May be time to put this out to pasture. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 100 100 051 - 18 2 Throughput_Performance -OS--K 252 252 000 - 0 3 Spin_Up_Time PO---K 045 045 025 - 16860 4 Start_Stop_Count -O--CK 098 098 000 - 2512 5 Reallocated_Sector_Ct PO--CK 252 252 010 - 0 7 Seek_Error_Rate -OSR-K 252 252 051 - 0 8 Seek_Time_Performance --S--K 252 252 015 - 0 9 Power_On_Hours -O--CK 100 100 000 - 15340 10 Spin_Retry_Count -O--CK 252 252 051 - 0 11 Calibration_Retry_Count -O--CK 252 252 000 - 0 12 Power_Cycle_Count -O--CK 098 098 000 - 2253 191 G-Sense_Error_Rate -O---K 100 100 000 - 53 192 Power-Off_Retract_Count -O---K 252 252 000 - 0 194 Temperature_Celsius -O---- 064 059 000 - 24 (Min/Max 14/41) 195 Hardware_ECC_Recovered -O-RCK 100 100 000 - 0 196 Reallocated_Event_Count -O--CK 252 252 000 - 0 197 Current_Pending_Sector -O--CK 100 100 000 - 1 198 Offline_Uncorrectable ----CK 252 252 000 - 0 199 UDMA_CRC_Error_Count -OS-CK 200 200 000 - 0 200 Multi_Zone_Error_Rate -O-R-K 100 100 000 - 83 223 Load_Retry_Count -O--CK 252 252 000 - 0 225 Load_Cycle_Count -O--CK 100 100 000 - 2526 SAMSUNG_HD103SJ_S246J1LSC01668-20180503-2023.txt
  6. ^^ this is exactly what I just did - I figured that since Tower used a 'default' network config it seemed like doing the same for Galahad would fix the problem - i.e. clear out the two files you've mentioned. And it did - been pinging 8.8.8.8 for 15-20 mins without a dropped packet. Basically the network config matched that of Tower, right down to the metrics used in the routing table, which was something I was trying to do manually but it just wouldn't configure the exact same way. Thanks for the response @John_M! (for anyone finding this after a Google search - do take a backup of your UnRaid USB drive before deleting the two files mentioned. You don't need to, but means you can recover back if you derp and delete more than the files you intended)
  7. I've been working on a new build to upgrade my increasingly elderly server (see the link below if interested). Lots of quirks, things to solve - and I make steady progress, then get another curveball that I have to solve. Except I'm stumped with this one. TLDR: I can set up a trial version (called 'Tower') with UnRaid 6.5.1 (with two disks). Connectivity is fine and I can ping 8.8.8.8 constantly without losing a ping. My 'regular' UnRaid 6.5.1 (called 'Galahad' with it's normal HDDs). Intermittent connectivity - pings to 8.8.8.8 work for about 50 pings, then fail for 50 pings, then start working, then stop, then start working again, then stop working for a bit, then start working again.... I'm stumped. I know there's differences in the network settings of the two versions and I've tinkered with different settings. It seems that the trial version defaulted to using bonding on both interfaces . Eth0 is the 'configured' interface, with Eth1 describing itself as 'not configured'. When I try to replicate the same setting with my 'regular' UnRaid software deployement (Galahad) I change it from Eth0 only (with Eth1 shutdown) to bonding on both interfaces. Only now it tells me that Eth1 is bonded. Something quirky is going on. It's the same Ethernet cable (I've tried both interfaces on both occasions) and the only hardware differences is the USB stick the software is held on and the HDDs that make up the array. Yet one seems to have perfect network connectivity....but the other one doesn't Help? Diagnostics for both deployments is attached - and the maddening part is I should be able to solve these networking problems by myself! galahad-diagnostics-20180501-1905.zip tower-diagnostics-20180501-2024.zip
  8. Don't have them yet - between the god-awful noises it was making and the fact that it didn't even get recognised in the BIOS I suspect it's dead. I have a new 2TB drive in now for the data rebuild (went to the store to pick up a drive before they closed for the evening). Once that's done I'll stand up that dodgy drive in the old server (prob tomorrow) and see if I can figure it out. But if the date on the front is anything to go by we're talking about a 9 y/o drive, so my expectations are quite low.
  9. Would you believe it! Adding the HDDs from my old server into this new one.....and it looks like one of the drives might have packed in! Worked in the old server (tested things yesterday to make sure)
  10. Very good points! Been pushing 160-ish GB of data over, deleting and then sending it again. I've got a lot to learn about reading syslog (it's something that I need to get good at) - but this jumped out at me at first glance. Note that this was my actions in removing the preclear plugin (GUI) since I wasn't going to use it. Therefore I don't see this as a concern - granted it generated a LOT of php error messages, but that was flagged in the preclear app thread: Apr 27 16:13:30 Tower emhttpd: req (9): csrf_token=****************&title=System+Log&cmd=%2FwebGui%2Fscripts%2Ftail_log&arg1=syslog Apr 27 16:13:30 Tower emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Apr 27 16:14:08 Tower login[13385]: ROOT LOGIN on '/dev/pts/0' Apr 27 16:14:33 Tower emhttpd: req (10): cmd=/plugins/dynamix.plugin.manager/scripts/plugin&arg1=remove&arg2=preclear.disk.plg&csrf_token=**************** Apr 27 16:14:33 Tower emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin remove preclear.disk.plg Apr 27 16:14:33 Tower root: plugin: running: anonymous Apr 27 16:14:34 Tower rc.diskinfo[13769]: killing daemon with PID [7260] Apr 27 16:14:37 Tower nginx: 2018/04/27 16:14:37 [error] 7226#7226: *42380 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.1.30, server: , request: "POST /plugins/preclear.disk/Preclear.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "10.0.1.34", referrer: "http://10.0.1.34/Main" Apr 27 16:14:37 Tower nginx: 2018/04/27 16:14:37 [error] 7226#7226: *42879 FastCGI sent in stderr: "Unable to open primary script: /usr/local/emhttp/plugins/preclear.disk/Preclear.php (No such file or directory)" while reading response header from upstream, client: 10.0.1.8, server: , request: "POST /plugins/preclear.disk/Preclear.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "10.0.1.34", referrer: "http://10.0.1.34/Plugins" Apr 27 16:14:37 Tower nginx: 2018/04/27 16:14:37 [error] 7226#7226: *42879 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.1.8, server: , request: "POST /plugins/preclear.disk/Preclear.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "10.0.1.34", referrer: "http://10.0.1.34/Plugins"
  11. So far so good. Drive bays are working and the new 4TB drive is calculating parity on the test array. Although part of me is wondering what I’m gaining by doing that - maybe my old-school is showing, but every drive that survived preclear has run for ever (I’ve had one failure). Just seems that that the time it will take to calculate and build th test parity is about the same time it will take to preclear - and the latter feels like a more comprehensive test? Ok sure, when parity is complete I can run an extended smart test which should flag any glitches......one to ponder ?
  12. Yeah that’s not a bad shout. I’ve got an ancient 200gb SATA drive lying around that can be wiped and dropped into a trial array of a single drive (afaik a single drive array is fine, just obviously unprotected). Test each hot swap bay in turn, verify that the drive can be at least seen, then preclear/test the new 4TB HDD. Once everything is good, introduce the existing drives with my licensed unraid usb drive. preclear: it’s less of a thing now judging from what I’ve read, but unraid does a “check” of its own?
  13. Thought I’d do a quick update about where I am with this: motherboard, cpu and ram successfully installed and able to reach BIOS BIOS flashed to latest version installed into case - got a fair bit of work to do to tidy the cabling up. The case doesn’t easily allow for neat cabling unfortunately To do: new case fans (3 x 120mm Noctua) as the chassis fans that came with the case are LOUD! port across existing HDDs. This is probably the bit I’m most nervous about since there’s lots of data on the drives finish off cabling once everything is working correctly, add the new 4TB drive as a new parity drive. TLDR: so far, so good!
  14. My 3U case from www.servercase.co.uk turned up yesterday. Well packaged, solid construction. My only gripe at the moment is the 'accessory box' would be more accurately described as 'a small bag of screws' - it's quite a decent mix to be fair, but if someone was planning a complete 16 HDD build then they may run out of screws for each caddy. There's 2 additional standoffs in the pack, and there's nine already in place inside the chassis itself. There's plenty of holes that the standoffs can probably be screwed into so almost any motherboard will work. Then again, I haven't started building the new server yet - so I may hate the chassis by the time I'm finished!!
  15. (In case someone else's Google searching brings them here) I raised the question with Asus support (before I got the response from jonathanm), who confirmed what was said above. To quote their response: