wheel Posted January 4, 2020 Share Posted January 4, 2020 Random, and possibly innocuous, but figured I'd check to see if this has ever happened to anyone before and been a warning sign: A strange folder is showing up among all my other user shares (named "1405986280") when I look at my unraid box's list of usual user shares in Kodi. It's not showing up in any of the individual drives viewed by Windows or Putty terminal. It's not showing up under /user or /user0. When I click on it in Kodi to try and access it, I'm warned that the share is not available. If I reset the Kodi system and go back to the folder list, the strange 10-digit folder is there and still inaccessible. Could someone have compromised my Unraid box and created some sort of folder like this for whatever purpose? If so, is there a good way to go about finding out when it happened if it didn't occur during my system's current log uptime? tower3-diagnostics-20200104-0231.zip Quote Link to comment
Squid Posted January 4, 2020 Share Posted January 4, 2020 You might want to look at better cooling, as these messages are being logged pretty much constantly Jan 3 19:02:31 Tower3 kernel: CPU7: Package temperature above threshold, cpu clock throttled (total events = 9496223) Jan 3 19:02:31 Tower3 kernel: CPU0: Package temperature above threshold, cpu clock throttled (total events = 9496160) 32 minutes ago, wheel said: It's not showing up in any of the individual drives viewed by Windows or Putty terminal. It's not showing up under /user or /user0. What's the output of ls -ail /mnt/user Quote Link to comment
wheel Posted January 4, 2020 Author Share Posted January 4, 2020 Yeah, I've been meaning to work on circulation - weekend project for sure! I ran ls -ail /mnt/user, and the 10-digit folder doesn't show up. Everything else looks in order. If nothing else seems off from the unraid end of things, I'm going to check with Kodi forums to see if that software has a history of "creating" weird folders like this that only it can see. Thanks for the swift help! Quote Link to comment
wheel Posted January 8, 2020 Author Share Posted January 8, 2020 (edited) Strangeness continues, with no new ideas on the Kodi front. Woke up this morning, and my tower's weirdly assigned to a different IP address. Feels like it's the first time it's ever happened in a decade of unraid usage. No new strange wireless or wired devices showing up on my network, but the old unraid address is now being held by a wireless device (iPad) which was turned on, connected to wifi, in the home, and completely untouched for hours before and hours after the swap. This looks like where it happened in the log; full diagnostics attached again. tower3-diagnostics-20200108-1542.zip Quote Jan 8 05:59:32 Tower3 dhcpcd[1703]: eth0: carrier lost Jan 8 05:59:32 Tower3 kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Down Jan 8 05:59:32 Tower3 avahi-daemon[3554]: Withdrawing address record for 10.0.0.11 on eth0. Jan 8 05:59:32 Tower3 avahi-daemon[3554]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.0.0.11. Jan 8 05:59:32 Tower3 avahi-daemon[3554]: Interface eth0.IPv4 no longer relevant for mDNS. Jan 8 05:59:32 Tower3 dhcpcd[1703]: eth0: deleting route to 10.0.0.0/24 Jan 8 05:59:32 Tower3 dhcpcd[1703]: eth0: deleting default route via 10.0.0.1 Jan 8 05:59:32 Tower3 dnsmasq[4383]: no servers found in /etc/resolv.conf, will retry Jan 8 05:59:34 Tower3 kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Jan 8 05:59:35 Tower3 dhcpcd[1703]: eth0: carrier acquired Jan 8 05:59:35 Tower3 kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Down Jan 8 05:59:35 Tower3 dhcpcd[1703]: eth0: rebinding lease of 10.0.0.11 Jan 8 05:59:36 Tower3 dhcpcd[1703]: eth0: carrier lost Jan 8 05:59:38 Tower3 kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Jan 8 05:59:38 Tower3 dhcpcd[1703]: eth0: carrier acquired Jan 8 05:59:38 Tower3 dhcpcd[1703]: eth0: rebinding lease of 10.0.0.11 Jan 8 05:59:43 Tower3 dhcpcd[1703]: eth0: probing for an IPv4LL address Jan 8 05:59:43 Tower3 dhcpcd[1703]: eth0: DHCP lease expired Jan 8 05:59:43 Tower3 dhcpcd[1703]: eth0: soliciting a DHCP lease Jan 8 05:59:48 Tower3 dhcpcd[1703]: eth0: using IPv4LL address 169.254.225.49 Jan 8 05:59:48 Tower3 dhcpcd[1703]: eth0: adding route to 169.254.0.0/16 Jan 8 05:59:48 Tower3 avahi-daemon[3554]: Joining mDNS multicast group on interface eth0.IPv4 with address 169.254.225.49. Jan 8 05:59:48 Tower3 dhcpcd[1703]: eth0: adding default route Jan 8 05:59:48 Tower3 avahi-daemon[3554]: New relevant interface eth0.IPv4 for mDNS. Jan 8 05:59:48 Tower3 avahi-daemon[3554]: Registering new address record for 169.254.225.49 on eth0.IPv4. Jan 8 05:59:56 Tower3 dhcpcd[1703]: eth0: carrier lost Jan 8 05:59:56 Tower3 kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Down Jan 8 05:59:56 Tower3 avahi-daemon[3554]: Withdrawing address record for 169.254.225.49 on eth0. Jan 8 05:59:56 Tower3 avahi-daemon[3554]: Leaving mDNS multicast group on interface eth0.IPv4 with address 169.254.225.49. Jan 8 05:59:56 Tower3 dhcpcd[1703]: eth0: deleting route to 169.254.0.0/16 Jan 8 05:59:56 Tower3 dhcpcd[1703]: eth0: deleting default route Jan 8 05:59:56 Tower3 avahi-daemon[3554]: Interface eth0.IPv4 no longer relevant for mDNS. Jan 8 06:00:00 Tower3 kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Jan 8 06:00:01 Tower3 dhcpcd[1703]: eth0: carrier acquired Jan 8 06:00:01 Tower3 dhcpcd[1703]: eth0: soliciting a DHCP lease Jan 8 06:00:06 Tower3 dhcpcd[1703]: eth0: probing for an IPv4LL address Jan 8 06:00:11 Tower3 dhcpcd[1703]: eth0: using IPv4LL address 169.254.225.49 Jan 8 06:00:11 Tower3 avahi-daemon[3554]: Joining mDNS multicast group on interface eth0.IPv4 with address 169.254.225.49. Jan 8 06:00:11 Tower3 dhcpcd[1703]: eth0: adding route to 169.254.0.0/16 Jan 8 06:00:11 Tower3 avahi-daemon[3554]: New relevant interface eth0.IPv4 for mDNS. Jan 8 06:00:11 Tower3 dhcpcd[1703]: eth0: adding default route Jan 8 06:00:11 Tower3 avahi-daemon[3554]: Registering new address record for 169.254.225.49 on eth0.IPv4. Jan 8 06:00:24 Tower3 dhcpcd[1703]: eth0: carrier lost Jan 8 06:00:24 Tower3 kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Down Jan 8 06:00:24 Tower3 avahi-daemon[3554]: Withdrawing address record for 169.254.225.49 on eth0. Jan 8 06:00:24 Tower3 avahi-daemon[3554]: Leaving mDNS multicast group on interface eth0.IPv4 with address 169.254.225.49. Jan 8 06:00:24 Tower3 dhcpcd[1703]: eth0: deleting route to 169.254.0.0/16 Jan 8 06:00:24 Tower3 avahi-daemon[3554]: Interface eth0.IPv4 no longer relevant for mDNS. Jan 8 06:00:24 Tower3 dhcpcd[1703]: eth0: deleting default route Jan 8 06:00:29 Tower3 kernel: igb 0000:05:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Jan 8 06:00:30 Tower3 dhcpcd[1703]: eth0: carrier acquired Jan 8 06:00:31 Tower3 dhcpcd[1703]: eth0: soliciting a DHCP lease Jan 8 06:00:31 Tower3 dhcpcd[1703]: eth0: offered 10.0.0.9 from 10.0.0.1 Jan 8 06:00:32 Tower3 dhcpcd[1703]: eth0: probing address 10.0.0.9/24 Jan 8 06:00:38 Tower3 dhcpcd[1703]: eth0: leased 10.0.0.9 for 86400 seconds Jan 8 06:00:38 Tower3 dhcpcd[1703]: eth0: adding route to 10.0.0.0/24 Jan 8 06:00:38 Tower3 avahi-daemon[3554]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.0.9. Jan 8 06:00:38 Tower3 dhcpcd[1703]: eth0: adding default route via 10.0.0.1 Jan 8 06:00:38 Tower3 avahi-daemon[3554]: New relevant interface eth0.IPv4 for mDNS. Jan 8 06:00:38 Tower3 avahi-daemon[3554]: Registering new address record for 10.0.0.9 on eth0.IPv4. Jan 8 06:00:38 Tower3 dnsmasq[4383]: reading /etc/resolv.conf Jan 8 06:00:38 Tower3 dnsmasq[4383]: using nameserver 10.0.0.1#53 Edited January 8, 2020 by wheel (more details) Quote Link to comment
trurl Posted January 8, 2020 Share Posted January 8, 2020 On 1/3/2020 at 10:31 PM, wheel said: A strange folder is showing up among all my other user shares (named "1405986280") when I look at my unraid box's list of usual user shares in Kodi. You mentioned looking at the "user shares" in Kodi, but you don't seem to see it in the user shares on Unraid. Maybe a screenshot of that Kodi listing and a screenshot of the User Shares in the Unraid webUI would help clarify. Quote Link to comment
trurl Posted January 8, 2020 Share Posted January 8, 2020 18 minutes ago, wheel said: Woke up this morning, and my tower's weirdly assigned to a different IP address. Feels like it's the first time it's ever happened in a decade of unraid usage. No new strange wireless or wired devices showing up on my network, but the old unraid address is now being held by a wireless device. Your Unraid is set to use DHCP, and that is the way I like to use it myself. That way I can do all my IP reservations in the router by MAC address. I recommend you do the same. Quote Link to comment
wheel Posted January 8, 2020 Author Share Posted January 8, 2020 Screenshots attached; "1405986280" is the weirdly inaccessible / not visible on the unraid side folder (Kodi's listing everything that shows up in the root directory of the unraid tower, including shares and actual disks). Thanks for the swift response! And yeah, knew about the DHCP setting, but I feel like I've never had an unraid tower "drop itself" and swap addresses with another device in the middle of a nighttime period of otherwise zero activity for a good while on either side - this and the weird folder got my paranoia tingling. Quote Link to comment
trurl Posted January 8, 2020 Share Posted January 8, 2020 That first screenshot includes many things that are not in your Unraid user shares so obviously there isn't any reason to suspect that "numbered" folder is in your user shares either. I don't use Kodi so I don't know where it is getting that list from. Quote Link to comment
wheel Posted January 8, 2020 Author Share Posted January 8, 2020 Yeah, Kodi buddies were mystified too and said it must have something to do with unraid. I'll probably just ignore it for now unless more weird things happen - no real "oh man someone's looking at my stuff" issues so much as "don't want my box to be part of some botnet" concerns. Quote Link to comment
wheel Posted January 8, 2020 Author Share Posted January 8, 2020 (edited) Aaaaand my IP just dropped and renewed on that box again out of nowhere. Logging from that happening up to most current log entry: Jan 8 17:14:39 Tower3 kernel: mdcmd (1048): spindown 4 Jan 8 17:49:39 Tower3 kernel: mdcmd (1049): spindown 1 Jan 8 18:00:38 Tower3 dhcpcd[1703]: eth0: NAK: from 10.0.0.1 Jan 8 18:00:38 Tower3 avahi-daemon[3554]: Withdrawing address record for 10.0.0.9 on eth0. Jan 8 18:00:38 Tower3 avahi-daemon[3554]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.0.0.9. Jan 8 18:00:38 Tower3 avahi-daemon[3554]: Interface eth0.IPv4 no longer relevant for mDNS. Jan 8 18:00:38 Tower3 dhcpcd[1703]: eth0: deleting route to 10.0.0.0/24 Jan 8 18:00:38 Tower3 dhcpcd[1703]: eth0: deleting default route via 10.0.0.1 Jan 8 18:00:38 Tower3 dnsmasq[4383]: no servers found in /etc/resolv.conf, will retry Jan 8 18:00:38 Tower3 dhcpcd[1703]: eth0: soliciting a DHCP lease Jan 8 18:00:39 Tower3 dhcpcd[1703]: eth0: offered 10.0.0.17 from 10.0.0.1 Jan 8 18:00:39 Tower3 dhcpcd[1703]: eth0: probing address 10.0.0.17/24 Jan 8 18:00:43 Tower3 dhcpcd[1703]: eth0: leased 10.0.0.17 for 86400 seconds Jan 8 18:00:43 Tower3 dhcpcd[1703]: eth0: adding route to 10.0.0.0/24 Jan 8 18:00:43 Tower3 dhcpcd[1703]: eth0: adding default route via 10.0.0.1 Jan 8 18:00:43 Tower3 avahi-daemon[3554]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.0.17. Jan 8 18:00:43 Tower3 avahi-daemon[3554]: New relevant interface eth0.IPv4 for mDNS. Jan 8 18:00:43 Tower3 avahi-daemon[3554]: Registering new address record for 10.0.0.17 on eth0.IPv4. Jan 8 18:00:43 Tower3 dnsmasq[4383]: reading /etc/resolv.conf Jan 8 18:00:43 Tower3 dnsmasq[4383]: using nameserver 10.0.0.1#53 Jan 8 18:19:10 Tower3 in.telnetd[17347]: connect from 10.0.0.16 (10.0.0.16) Jan 8 18:19:11 Tower3 login[17348]: ROOT LOGIN on '/dev/pts/2' from '10.0.0.16' Edited January 8, 2020 by wheel added logging from before IP drop Quote Link to comment
itimpi Posted January 8, 2020 Share Posted January 8, 2020 The normal way to stop this sort of event potentially causing a problem is to set the router to reserve the IP address that Unraid is to use. That way you can be sure that no other device on the LAN can be given that address Quote Link to comment
wheel Posted January 8, 2020 Author Share Posted January 8, 2020 For sure; that's what I'm going to do with this and my other unraid boxes, but since it's never happened before and it's happening twice in relatively quick succession now, I figured I should check in here in case that's a symptom of something else weird going on under the hood. I'm a ridiculously basic user with almost no linux experience, so I realize this could all be totally innocuous - it's the fact that I've run this specific setup (network, unraid, kodi, no changes) for years with no issues, but two strange things are happening concurrently, that's kind of freaking me out. I'm really appreciating all the eyes on this and advice from everyone, though! This place is the best. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.