7 minutes ago, Squid said:

Install the nerd pack plugin via the apps tab. Set need pack to install mcelog. Reboot and wait for the error again

 

 

I have nerd pack and mcelog installed, I just don't know where it is?  Where do I find the mcelog?  

Its a command line (mcelog)  Next time an mce happens, the output from mcelog will be logged in the syslog so that diagnostics will show it.

Over the past couple years I've amassed a ton of duplicates for a multitude of reasons. I know the extended test finds these, but from what I can tell it does not actually delete anything but only reports the duplicates? Is there a way to remove the duplicates on a mass scale? There are far too many duplicates to go in and try to clean up manually.

5 hours ago, SuperNotSupper said:

Over the past couple years I've amassed a ton of duplicates for a multitude of reasons. I know the extended test finds these, but from what I can tell it does not actually delete anything but only reports the duplicates? Is there a way to remove the duplicates on a mass scale? There are far too many duplicates to go in and try to clean up manually.

Not that I'm aware of.

 

Duplicates are duplicate names in the same share but on different disks, not necessarily duplicated data.  The problem you have is when the files differ from each other, which do you delete.

 

Rather surprised that you've got duplicates at all.  In this day using the user share system you should never wind up with one.

I get an md5 error with today's plugin update:

 

plugin: updating: fix.common.problems.plg
plugin: downloading: https://raw.github.com/Squidly271/fix.common.problems/master/archive/fix.common.problems-2017.10.15-x86_64-1.txz ... done
plugin: bad file MD5: /boot/config/plugins/fix.common.problems/fix.common.problems-2017.10.15-x86_64-1.txz

@tstor I'm getting the same problem. It's not just you 

43 minutes ago, maniacalyeti said:

@tstor I'm getting the same problem. It's not just you 

 

46 minutes ago, tstor said:

I get an md5 error with today's plugin update:

 

plugin: updating: fix.common.problems.plg
plugin: downloading: https://raw.github.com/Squidly271/fix.common.problems/master/archive/fix.common.problems-2017.10.15-x86_64-1.txz ... done
plugin: bad file MD5: /boot/config/plugins/fix.common.problems/fix.common.problems-2017.10.15-x86_64-1.txz

That's my bad.  Pushed the change, then didn't have a chance to check before I had to run out.  Try it again  2017.10.15a

Dang -- Yeah I have quite a big list. I'm not sure how they were formed. I recently reformatted to XFS so maybe they got duped during the file shuffle? I also had to do some RFS file recovery a little while back. Could be from that too. I really don't have enough time to go in and try to clean the list up. I'll just assume at worst case scenario it's causing wasted space.

 

 

15 hours ago, Squid said:

Not that I'm aware of.

 

Duplicates are duplicate names in the same share but on different disks, not necessarily duplicated data.  The problem you have is when the files differ from each other, which do you delete.

 

Rather surprised that you've got duplicates at all.  In this day using the user share system you should never wind up with one.

 

5 minutes ago, SuperNotSupper said:

Dang -- Yeah I have quite a big list. I'm not sure how they were formed. I recently reformatted to XFS so maybe they got duped during the file shuffle? I also had to do some RFS file recovery a little while back. Could be from that too. I really don't have enough time to go in and try to clean the list up. I'll just assume at worst case scenario it's causing wasted space.

 

 

 

What about dupeGuru.

Fix Common Problems reported an 'error' on my qbittorrent container with version 2017.10.15a.

 

The last version reports an issue with my qbittorrent docker port not being the default 8080.  But I actually had to change the port due to conflict with other docker as explained on https://hub.docker.com/r/linuxserver/qbittorrent/

 

Due to issues with CSRF and port mapping, should you require to alter the port for the webui you need to change both sides of the -p 8080 switch AND set the WEBUI_PORT variable to the new port.

For example, to set the port to 8090 you need to set -p 8090:8090 and -e WEBUI_PORT=8090

 

I tried only changing (one side) the host port as suggested by Fix Common Problems, but this doesn't seem to work for this container.

Edited October 16, 20178 yr by themaxxz

All versions of FCP would issue the same error.  FCP highlights things that tend to trip people up.  As with in the world, there may be valid reasons to do what is seemingly wrong.  Just ignore the error.

It was suggested that I post my issue to this thread.

Long story short...I have some folders I am unable to access and the New Perms Tool hasn't been able to fix the permissions.

Here is the original thread and the steps I have tried to fix the problem (thanks to the guidance of Frank1940):

 

37 minutes ago, dan4081 said:

It was suggested that I post my issue to this thread.

Long story short...I have some folders I am unable to access and the New Perms Tool hasn't been able to fix the permissions.

Here is the original thread and the steps I have tried to fix the problem (thanks to the guidance of Frank1940):

 

I tried it recreating the same folder structure and permissions that were listed in your thread, and upon running the script the permissions did get reset accordingly.  I suspect that the drive those file(s) are on is mounted read-only.  Diagnostics would tell the story.

 

Thanks for the reply.

Hope this is what you needed:

tower-diagnostics-20171111-2058.zip

Nov 11 12:39:58 Tower emhttp: cmd: /usr/local/emhttp/plugins/fix.common.problems/scripts/newperms.sh
Nov 11 12:51:05 Tower kernel: REISERFS warning: reiserfs-5089 is_internal: free space seems wrong: level=2, nr_items=149, free_space=360 rdkey 
Nov 11 12:51:05 Tower kernel: REISERFS error (device md4): vs-5150 search_by_key: invalid format found in block 410131594. Fsck?
Nov 11 12:51:05 Tower kernel: REISERFS (device md4): Remounting filesystem read-only

You need to Check Disk Filesystem on disk 4

Also, you really shouldn't be trying to run unRaid on 1 Gig of memory.  I would say the functional minimum is 2 Gig as a basic fileserver

 

Quote

Nov 11 12:38:41 Tower root: Fix Common Problems: Error: Rootfs file is getting full (currently 98 % used)

 

Went through the steps to check the file system (--rebuild-tree) and now the disc comes up as unmountable (no file system 32)

 

reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/md4
Will put log info to 'stdout'
###########
reiserfsck --check started at Sat Nov 11 21:53:35 2017
###########
Replaying journal:
Replaying journal: Done.
Reiserfs journal '/dev/md4' in blocks [18..8211]: 0 transactions replayed
Checking internal tree..

Bad root block 0. (--rebuild-tree did not complete)

 

Nextstep?

5 hours ago, dan4081 said:

Nextstep?

 

Earlier --rebuild-tree didn't complete, almost certainly from running out of memory, output would confirm, but you need at least 1GB per TB for running --rebuild-tree successfully.

So I guess first step would be to add more memory and try rebuild tree again. I will see what I can find locally today.

Thanks

27 minutes ago, dan4081 said:

So I guess first step would be to add more memory and try rebuild tree again. I will see what I can find locally today.

Thanks

 

Yes, if possible get 4GB, but 2GB *should* be enough.

Of course...Office Depot doesn't carry ram, Staples I usually go to was closed down and best buy was out of all DDR3 for desktops in store.

Ill order some from Amazon and get it here Tuesday....

 

Edit: Bought a 4gb stick from Amazon with one day shipping. It should be at my house when I get home from work.

Ill update this thread after I put it in and re run the script.

Edited November 13, 20178 yr by dan4081

Success!

Changing over to 4gb of Ram worked wonders. 

New Perms now fixed the problem, and my Unraid is much 'snappier' with the 4gb compared to the 1gb I had in there.

 

Thanks to everyone who helped!!!

I've created VLANs recently and assigned IPs to most of my dockers and sometimes a VLAN.  I don't think CA should throw these up as errors e.g. beets running in bro.10 mode rather than bridge isn't an error:

 

Switched FCP to ignore the test if you're not running in host or bridge mode.  Too many complexities if running in other network modes (that I can't test)

Warning: A non-numeric value encountered in /usr/local/emhttp/plugins/fix.common.problems/include/tests.php on line 1085

 

This shows after the recent update.