I recently had what seems like a false positive for the miner detection. It was a warning that xmrig was running but I couldn't see it in top, and neither my CPU or GPU have been under any load recently. It popped up once and disappeared after a rescan.

 

I've checked some of the common security problems, and I only have ports opened for torrent clients (I double checked and I can't access ssh, the Unraid webui, or any container's webui from outside my network), I haven't installed any new plugins or docker containers in weeks, and I haven't changed any settings in weeks. The only things that have happened recently are updates to my Jellyfin and NetData containers a few hours ago. I've also never installed anything mining-related on my server.

 

This is on version 2021.4.11

cooper-diagnostics-20210415-1646.zip

You rebooted after the warning came up, and it's not finding it now, so I can't tell what may have triggered it.

On 4/16/2021 at 4:35 AM, Squid said:

You rebooted after the warning came up, and it's not finding it now, so I can't tell what may have triggered it.

Unless we're talking about different things, I definitely didn't reboot between the getting the warning and downloading the diagnostics. You can see "Possible mining software running" at 15:56 towards the end of the syslog.

 

That being said, it hasn't happened again in the past few days and I haven't noticed anything strange so I can't provide any extra info at the moment.

Yeah, I missed that, and only was looking at the last one which didn't find it

Hi

Can we get a check for this file if Mover Tuning is installed?

/boot/config/plugins/ca.mover.tuning/ca.mover.tuning.cfg

 

Unless that file is not supposed to persist. 

It seems that maybe updating to 6.2 is removing the file.  I have not updated just yet (will this weekend to verify)

 

Thanks

On 5/21/2016 at 5:32 PM, switchman said:

 

Here you go.  Change as appropriate.

http://permissions-calculator.org/decode/0755/

One further question:

I have been add my users to the user group for getting write access with the access of 0775. It should give the writing access for the logged user.  I am using NFS for the Network FS. In this forum I recognized NFS is not behaving as usual but needs fill 0777 access?

OK,  I try to change the access rights:

 

find . -type d -exec chmod 0777 {} \;
find . -type f -exec chmod 0666 {} \;

 

Is there a compelling reason that there is a Red error notification when there is a update for the plugin?

from my perspective this should not be red since it's just a plugin update not something really bad....

There have been quite some Updates the last couple of weeks and I still jump every time I see a red error 😬

 

Edited April 29, 20215 yr by LammeN3rd

I see a couple people have posted this question, but it appears they haven't followed through on requests for additional info and so I haven't found the answer yet. When running this (very helpful) plugin, I have thousands of files that show an error like this:

 

/mnt/user/plex/Library/Application Support/Plex Media Server/Media/localhost/1/0454c92c03b598eedae0c9f932de9133343c387.bundle/Contents/Subtitles/en/com.plexapp.agents.opensubtitles_2ef7e934bea6d5356e6ed66495b22786fe855a58.srt   root/root (/)  0

 

All are related to Plex, but it could be art/posters/etc. I ran "Docker Safe New Perms" but it didn't impact these. ls -l for that file shows:

lrwxrwxrwx 1 nobody users 231 Feb 28 14:24

 

I've confirmed that it doesn't show up in explorer. Plex can't read the subtitles either. I couldn't chmod it because it gives a "cannot operate on dangling symlink" error. I'd appreciate if someone could help me resolve this or let me know what additional info would be helpful. Thank you

The "plex" share isn't being excluded from the extended tests (as it looks like it's outside your existing appdata share)  Add it to the exclusion list.

 

Can't help with the subtitle thing.

 

BTW, extended tests don't really do much except for checking for issues with sharing over the network, so not much reason to ever run them...

50 minutes ago, Squid said:

The "plex" share isn't being excluded from the extended tests (as it looks like it's outside your existing appdata share)  Add it to the exclusion list.

 

Can't help with the subtitle thing.

 

BTW, extended tests don't really do much except for checking for issues with sharing over the network, so not much reason to ever run them...

Well, I suppose if there's not a real issue, that's why I haven't seen a real solution 😛 Thanks. I'll get it excluded. I know it may not seriously matter, but I like it when tests come back clean. Stupid OCD...

They never will if run against a share that contains appdata

On 4/10/2021 at 1:14 PM, Squid said:

Fixed

 

 

Also on today's update, a new warning will be issued under 2 circumstances:

 

The string xmrig is found in your go file, or a process named xmrig is running.

 

If it's found in your go file, then most likely your entire system has been compromised and a hacker has edited your go file to automatically install xmrig on every boot

 

If it's a process, two scenarios exist

1. You're purposely running it.  In which case this warning is safe to ignore
2. You've possibly installed a compromised container via a random dockerHub search that is masking the fact that it's installing xmrig as it's primary purpose.

 

For reference, xmrig is mining software, and since malware, viruses, ransomware etc are now passe, Compromising a system to instead mine for bitcoin is the hack of choice.

 

Had the xmrig warning appear. I do not do any mining on my unraid system at all. After running FCP manually it did not return that warning again. Is there anything I can do to check my container images to see if any might be triggering xmrig to be running? What would your recommendations be?

EDIT: here are the only lines I can seem to find in the diagnostics that reference it -

### [PREVIOUS LINE REPEATED 1 TIMES] ###
May  3 15:59:00 UnraidCore root: FCP Debug Log: root     32685  0.0  0.0   3848  2884 ?        S    15:58   0:00 sh -c ps -aux | grep -i xmrig
### [PREVIOUS LINE REPEATED 1 TIMES] ###
May  3 15:59:00 UnraidCore root: FCP Debug Log: root     32686  0.0  0.0   3848  2952 ?        S    15:58   0:00 sh -c ps -aux | grep -i xmrig
### [PREVIOUS LINE REPEATED 1 TIMES] ###
May  3 15:59:00 UnraidCore root: FCP Debug Log: root     32688  0.0  0.0   3260   768 ?        S    15:58   0:00 grep -i xmrig
### [PREVIOUS LINE REPEATED 1 TIMES] ###
May  3 15:59:00 UnraidCore root: FCP Debug Log: root     32690  0.0  0.0   3260   832 ?        S    15:58   0:00 grep -i xmrig
### [PREVIOUS LINE REPEATED 1 TIMES] ###
May  3 15:59:00 UnraidCore root: Fix Common Problems: Warning: Possible mining software running
### [PREVIOUS LINE REPEATED 1 TIMES] ###

unraidcore-diagnostics-20210503-1718.zip

Edited May 3, 20215 yr by Dynizzle

Thanks for that.  I know what the problem is, and it is a false positive (Somehow you've got the scan running twice concurrently)  Should have an update out tomorrow.  Now

On 3/27/2020 at 9:38 AM, Squid said:

Yeah, the all ignored could / should be collapsed by default, since it's simply a history of everything you've ignored regardless of it's its found again.

Sorry to necro reply to this. I searched the thread for the word collapse and found your comment. It doesn't seem like ignored items are collapsed or even collapsable.

Is there a setting for this that I'm missing?

 

Unraid 6.9.2

FCP 2021.05.03

No, there're not collapsible.  They're just ignored...

13 minutes ago, Squid said:

No, there're not collapsible.  They're just ignored...

Would you consider adding the ability to collapse sections? (And maybe either collapse ignored sections by default, or make it an option to do so). Every time I open the page I see (the screenshot) all the items I've intentionally ignored. It would be nice if the only things that grab my attention were things I haven't ignored.

Apparently I already have, since you quoted me saying so  Of course, I forgot all about it.  

I am sure it is written anywhere in the last 58 pages but where can I find a complete list of what exactly is or can be tested and how? In short: a manual.

 

Especially, I am wondering about the exclusion list and the extented disk test as well as the on page 2 or 3 mentioned duplicate file check test.

 

While I think an overall healthy configuration check would be useful, I do not find it very healthy if the content of my 150 TB array would be regularly scanned completely. But I am not sure if that is the case... so what this plugin really does and wich things can be disabled.

Edited May 14, 20215 yr by tardezyx

36 minutes ago, tardezyx said:

complete list of what exactly

The "What is tested" button on the settings screen

 

37 minutes ago, tardezyx said:

and how?

https://github.com/Squidly271/fix.common.problems/blob/master/source/fix.common.problems/usr/local/emhttp/plugins/fix.common.problems/include/tests.php

38 minutes ago, tardezyx said:

Especially, I am wondering about the exclusion list and the extented disk test as well as the on page 2 or 3 mentioned duplicate file check test.

Extended tests (which is what the exclusion list refers to) are only ever run on demand and basically check for illegal characters / sharing problems on every file.

On the settings page it says "Docker Appdata Folders and CA backup Destination is automatically excluded". Does this not also apply to the "Docker Safe New Perms" tool? My CA Backup destination is "/mnt/cache/appdata-bup" but when the tool runs it says "Processing '/mnt/cache/appdata-bup'" and changes the permissions on the backup files.

Probably a message still in there from v1.  v2 uses a tarball, so permissions are irrelevant as it won't open up the tar anyways.

Hello everyone,

 

I ran an "Extended test", but it seems to be stuck. One of my shares has 1m documents (for a total of 1.3TB), and it has been scanning it for more than an hour.

 

CPU usage of the extendedTest.php script is 20%, and for the shfs process it's 100%. Weirdly, there is no disk activity. Even iotop shows 0 everywhere.

 

I think reorgonazing my shares so that they contain less files would solve the issue, but I still wanted to ask if that's expected behaviour. Maybe it will finish in an hour or two. I'll update this post if so.

Edited June 14, 20215 yr by wblondel

any way to change default start up time? I've set it up to daily, and it fires in the middle of the night, preventing my hdd to sleep properly (I only use server in the evening and sleep is set afeter 4 hours).

 

Thanks!

Dynamix Schedules plugin.  Allows you to change the hourly / daily schedule for when things run.