I have gotten a couple of these error in the common problems plugin. I'm not sure what this is or where to begin?

nas-diagnostics-20191215-1059.zip

I forgot to state. Running latest. 6.8.0 nvidia. Also happened on 6.8.0 rc9

5 minutes ago, Natebur said:

I'm not sure what this is or where to begin?

You can begin by posting in the correct place.

 

You posted in the section for bug reports, but you were not reporting a bug. I have closed that report and copied your post to a new thread here in the General Support forum.

 

Dec 15 04:40:14 NAS root: Transaction: Memory read error

Bad ram stick most likely

 

Also, disable the debugging on the parity check tuning plugin.

Have you done a memtest? (on the boot menu)

Also, I noticed you have a ridiculously large number (150) of share .cfg files in your diagnostics. Many of these don't appear to be actual shares with any files. Possibly you accidentally created them at some point by writing to the root of one or more disks. Any folder at the top level is automatically a share.

 

It would help future diagnostics if you could just delete all these extra share .cfg files from your flash. They are in config/shares on your flash drive.

 

And, I notice you have 40G allocated to docker image. I usually recommend 20G and your are very unlikely to need even that much unless you have misconfigured applications. Have you had problems with docker image filling? Making it larger will not fix that, it will only make it take longer to fill.

I appreciate the quick response and the corrected location. I will try to do the mem test today. I didn’t know about the cfgs and I will look at this. My docker is currently at 11 gbs. A while back I had an issue with my docker expanding and had it again recently. I didn’t know what to look for as to why. 

57 minutes ago, Natebur said:

A while back I had an issue with my docker expanding and had it again recently. I didn’t know what to look for as to why. 

There are 2 main ways dockers can get out of hand and fill things.

1. This one is due to settings within the application. If the application is writing to a path that isn't mapped, that is writing into the docker image and filling it. Common mistakes are not using the same upper/lower case as in the mappings, or not using an absolute path (beginning with /), or possibly even not actually having a mapping for the path.
2. This one is due to settings of the docker. If a host path isn't actual storage, it is in RAM possibly filling it and bringing the server down. Note that this also applies to a path to an Unassigned Device that isn't actually mounted.

We can take a look at this later.