MrLeek
-
Posts
109 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by MrLeek
-
-
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.
QuoteTime Of Attack:Thu, 24 May 2018 08:49:55 +0000
Attacked File: /mnt/user/able-galahad/.DS_Store
Samba version 4.7.7
PID Username Group Machine Protocol Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
31553 nobody users fe80::18e0:fb1d:1a2e:7d46 (ipv6:fe80::18e0:fb1d:1a2e:7d46:49589) SMB3_02 - -
Service pid Machine Connected at Encryption Signing
---------------------------------------------------------------------------------------------
able-galahad 31553 fe80::18e0:fb1d:1a2e:7d46 Thu May 24 08:49:50 2018 UTC - -
IPC$ 31553 fe80::18e0:fb1d:1a2e:7d46 Thu May 24 08:49:54 2018 UTC - -
cache 31553 fe80::18e0:fb1d:1a2e:7d46 Thu May 24 08:48:29 2018 UTC - -
were-galahad 31553 fe80::18e0:fb1d:1a2e:7d46 Thu May 24 08:49:03 2018 UTC - -
Locked files:
Pid Uid DenyMode Access R/W Oplock SharePath Name Time
--------------------------------------------------------------------------------------------------
31553 99 DENY_NONE 0x100081 RDONLY NONE /mnt/cache . Thu May 24 08:48:44 2018 -
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.
-
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
-
On 4/30/2018 at 8:35 PM, jonathanm said:
diagnostics?
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 -
^^ 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)
-
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!
-
30 minutes ago, jonathanm said:
diagnostics?
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.
-
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)
-
15 hours ago, jonathanm said:
At this point, you aren't just testing the drive, you are testing the entire rig, RAM, CPU, HBA, PSU, and any other TLA's I forgot.
Watch your syslog for any anomalies, just make sure everything is working well.
Last thing you want is for a dodgy bit of RAM to start corrupting the data on the drives you are going to introduce already filled with data.
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" -
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 ?
-
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?
-
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!
-
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!!
-
On 22/04/2018 at 9:02 PM, jonathanm said:
Yes, definitely! Those pins are extremely delicate, and should be protected either by a CPU or the cover that came with the board.
The motherboard manual should have a warning about leaving it open.
(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:
QuoteYes, you can leave the protective cover on.
It is not mandatory, it can be removed - but if it is not used, it's best to keep it covered, in case something falls and damages the pins on the socket -
I mention this one due to the language being used - it describes the SATA ends as "hosts" and the SFF-8087 as the "target" - that's basically a reverse connection/cable?
-
1 minute ago, uldise said:
Or this one: https://www.amazon.com/Cable-Matters-Internal-Mini-SAS-Breakout/dp/B018YHS9GM?th=1
Shame it'll take a week to get here
-
1 minute ago, jonathanm said:
Yes, it's clearer to use controller - drive terminology.
single controller connection -> multiple sata drives = forward breakout
multiple controller connections -> drive backplane single connection = reverse breakout
Also consider which 'end' is doing the work. If the motherboard is where the controller is, then it has to be a reverse connection into the backplate
-
It would be the more expensive cable (and one that seems to be harder to get hold of!) - cheers both, much appreciated!
-
cheers for the link - unless i'm going mad this is the key sentence for me:
If The Motherboard/host-Controller side are SATA connectors and the backplane is a SAS connector then you must always use a SAS to SATA Reverse Breakout Cable. "
That is right......right?
-
99% certain that I need a REVERSE SATA/SAS breakout cable (since i'm going from motherboard SATA ports to a SFF-0807 backplate). Wrting this partly so that i can get corrected as needed....and also to keep on track whilst I search for the right cable - the number of times I've ended up looking at the wrong type of cable because Google/Amazon is trying to 'help' me....grrr!!
-
That's what I expected as well. Instead there's a clear 'keep the protective socket caps (in case of RMA)' message and the fact that the motherboard can indeed run using just one CPU. But no specific instruction on what to do with the unused socket - so thanks for the response @jonathanm
Other news - the chassis from Server Case turned up today. Really impressive looking thing in the flesh.....I just have to figure out how to connect the hot-swap drives up to the rest of the server. Looks like one bank of 4 drives has 4-pin Molex power connections and the next block of 4 has what (at first glance) appear to be SATA connections. But, unless I'm blind, there's no other connections....let me take a good look at this thing......
edit: a picture is worth a thousand words so they say....
Edit 2: It looks like this is a SAS - SATA connection thing (never encountered it before). Looks like these cables will fit: https://www.newegg.com/global/uk/Product/Product.aspx?Item=N82E16812117624&cm_re=mini_sas_to_sata-_-12-117-624-_-Product
Question - are SAS <> SATA cables into the motherboard likely to cause me a headache or three?
-
....and dumb question of the day:
If i'm running this mobo with just one CPU, do I keep the CPU slot cap on the unused socket? I assume I do, but sods law says I'll blow the 2nd CPU socket!
-
In fact, the only thing I’d love to find other options is the case it’s all going to go in. There’s just not that many options when the mobo is an EEB (not helped that if I did find a good looking tower case I’d want it to be in silver)
-
1 hour ago, Jcloud said:
I see Crucial in your picture, also good pick for RAM.
Yeah both are excellent. I looked up the specific ram models that were compatible for the board and found more options for Crucial. No other reason
-
1
-
Possible Ransomware Attack?
in General Support
Posted
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...