On 12/30/2024 at 12:17 PM, mhorn said:

When I tried to upgrade from 2024.12.19 to 2024.12.19a, I saw this message:

Update Plugin

plugin: updating: fix.common.problems.plg
Executing hook script: pre_plugin_checks
plugin: XML file doesn't exist or xml parse error
Executing hook script: post_plugin_checks

 

And now it is stuck as pending.

 

From the terminal,

 

rm /tmp/plugins/pluginPending/*

 

or reboot

The past days nothing happens when I click on "Fix Common Problems" from Settings.
It says "scanning" but the parentage does not show and it just seems stuck.

Anyone else have this happened lately?

40 minutes ago, isvein said:

The past days nothing happens when I click on "Fix Common Problems" from Settings.
It says "scanning" but the parentage does not show and it just seems stuck.

Anyone else have this happened lately?

Would imply that nchan is failing for some reason.  FCP though is designed that if you wait a couple of minutes and then reload the page it should bring up the problems it finds.  Otherwise, post your diagnostics

Can I get some help with logs getting full? I have rebooted and upgraded firmware and problem still persantharas-diagnostics-20250102-1050.zipists. 

 

Any Help would be great. 

 

Thank you.

14 minutes ago, reapa said:

Can I get some help with logs getting full? I have rebooted and upgraded firmware and problem still persantharas-diagnostics-20250102-1050.zipists. 

 

Any Help would be great. 

 

Thank you.

/var/log
total 76312
-rw-r--r-- 1 root   root    17458 Dec  7 08:30 Xorg.0.log
-rw------- 1 root   root        0 Nov 27 16:00 btmp
-rw-r--r-- 1 root   root 16190982 Jan  2 10:51 cache_dirs.csv
-rw-r--r-- 1 root   root 58609986 Jan  2 10:51 cache_dirs.log
-rw-r--r-- 1 root   root      182 Dec  7 08:30 cache_dirs_lost_cache.csv
-rw-r--r-- 1 root   root        0 Apr 29  2021 cron
-rw-r--r-- 1 root   root        0 Apr 29  2021 debug
-rw-r--r-- 1 root   root    92468 Dec  7 08:29 dmesg
-rw-r--r-- 1 root   root    23392 Jan  1 00:04 docker.log
-rw-r--r-- 1 root   root     7008 Dec  7 08:29 faillog
-rw-r--r-- 1 root   root  2656496 Jan  2 10:50 file.activity.log

Looks like you've got logging enabled in folder caching and file activity plugins. Those options probably aren't meant to be enabled for long periods of times

3 hours ago, Squid said:

Would imply that nchan is failing for some reason.  FCP though is designed that if you wait a couple of minutes and then reload the page it should bring up the problems it finds.  Otherwise, post your diagnostics

Tried, nothing happened.
Tried in another browser, same thing

oneroom-diagnostics-20250102-0142.zip

2 hours ago, Squid said:

/var/log
total 76312
-rw-r--r-- 1 root   root    17458 Dec  7 08:30 Xorg.0.log
-rw------- 1 root   root        0 Nov 27 16:00 btmp
-rw-r--r-- 1 root   root 16190982 Jan  2 10:51 cache_dirs.csv
-rw-r--r-- 1 root   root 58609986 Jan  2 10:51 cache_dirs.log
-rw-r--r-- 1 root   root      182 Dec  7 08:30 cache_dirs_lost_cache.csv
-rw-r--r-- 1 root   root        0 Apr 29  2021 cron
-rw-r--r-- 1 root   root        0 Apr 29  2021 debug
-rw-r--r-- 1 root   root    92468 Dec  7 08:29 dmesg
-rw-r--r-- 1 root   root    23392 Jan  1 00:04 docker.log
-rw-r--r-- 1 root   root     7008 Dec  7 08:29 faillog
-rw-r--r-- 1 root   root  2656496 Jan  2 10:50 file.activity.log

Looks like you've got logging enabled in folder caching and file activity plugins. Those options probably aren't meant to be enabled for long periods of times

Thank you

It works now again after update to Unraid 7

Fix Common Problems just threw a warning I've never seen before and I'm having trouble figuring out what to do to resolve it:
"Invalid folder cache contained within /mnt"

I looked at the folders I have in /mnt , but I don't know which one is invalid or how it would have gotten created:

 

 

 

I'm guessing the offending folder is either /rootshare  /remotes or /addons as I know the others are valid. I'm sure it is an easy fix, but I'm not really sure how to resolve this, so any help would be greatly appreciated.

unraidplex-diagnostics-20250112-0652.zip

Actually, it turned out to be /cache . For some reason, an old Docker container that I'm not using was set to use it. I removed the container, removed all traces of it from appdata and rebooted. Now that share is no longer there and the warning in FCP is gone. Even easier fix than I imagined it would be! 

CA Mover Tuning by hugenbdd doesn't work with 7.0 (doesn't actually move files), but update assistant is not marking it as incompatible.

Any way it could be added?

On 1/17/2025 at 9:42 AM, melagodo said:

CA Mover Tuning by hugenbdd doesn't work with 7.0 (doesn't actually move files), but update assistant is not marking it as incompatible.

Any way it could be added?

What say hugenbdd in his Plugin Thread?

Hi All, I have just started getting the following error when running Fix Common Problems -

 

/boot/config/ultra.cfg corrupted

 

A number of things I have tried to resolve the issue -

 

* Renamed ultra.cfg to old.ultra.cfg then copied ultra.cfg from a USB Backup from a number of months ago, rebooted and error still appears (now is listed twice, one for ultra.cfg and another for old.ultra.cfg)

* Deleted ultra.cfg and rebooted hoping that Unraid would rebuild the file (it did not) so copied back saved copy of file.

 

As far as I can tell it does not seem to be affecting the usage of the server, no other errors other then in Fix Common Problems.

I can still open ultra.cfg via the UNRAID file manager and see the contents of the file.

 

Any ideas? should I be looking at replacing the USB with another?

 

unraid-diagnostics-20250119-1448.zip

It's a valid file, but for some reason PHP thinks its corrupt (due to the "]" at the end of the comment lines).

 

I'll look into it.

 

What file is this for?

I actually have no idea what this file is used for, there is content in the file.

 

Removing it did not seem to have a effect on the system (not that I encountered any way)

It looks like its part of another file dynamix.cfg (but corrupted).  I'd delete it

Possible false positive on unRAID 7.0: 

Share XXXXXXXXXXX set to use pool cache, but files / folders exist on the storage_ssd pool

 

I moved to unRAID 7 this week and I now have an array-free setup on one of my servers.

 

I have 3 pools as below:

 

Cache: internal NVME drive

External_ssd: external 2TB drive for archive of Frigate recordings

Storage_ssd: internal 1TB SSD

 

 

Shares set up as below:

 

 

I get the following warnings in FCP for the shares using more than one pool:

 

 

 

I would have thought that this was the desired behavior and not something to be warned about?

Files should exist between the primary & secondary storage locations as per the mover settings.

 

shareDisks.txt:

appdata                           shareUseCache="only"    # Share exists on cache
domains                           shareUseCache="only"    # Share exists on cache
F---------------s                 shareUseCache="yes"     # Share exists on storage_ssd, external_ssd
isos                              shareUseCache="yes"     # Share exists on storage_ssd
S-----e                           shareUseCache="yes"     # Share exists on cache, storage_ssd
system                            shareUseCache="only"    # Share exists on cache

 

Full diagnostics attached:

 

 

Thanks so much for your work for the community @Squid.

 

 

tower-diagnostics-20250119-1720.zip

Edited January 19, 20251 yr by Capt.Insano
typo

Hi there,

I'm getting this in fix common problems - "Invalid folder cache contained within /mnt". Hoping someone is able to help me figure out the culprit. Thank you!

tower-diagnostics-20250119-2023.zip

Share Cloud_Data set to not use the cache, but files / folders exist on the cache drive

There are a few more shares and I followed these steps which are recommended: 

• Stop Docker and VM services in Settings

• Change the settings of the share to Use Cache: yes and then run mover.

• After mover has finished, set the use cache settings back to no and enable the docker and VM services again.

• Btw a scrub of the cache drives ended with 0 errors

Help is much appreciated. 

Edited June 28, 20251 yr by EdgarWallace

9 hours ago, LakersFan said:

Hi there,

I'm getting this in fix common problems - "Invalid folder cache contained within /mnt". Hoping someone is able to help me figure out the culprit. Thank you!

tower-diagnostics-20250119-2023.zip 200.96 kB · 0 downloads

You've got a docker container referencing on one of its paths /mnt/cache/... and you do not have a pool named "cache" - only a pool named "cache_nvme". Edit each container and update the path appropriately

 

(Because of this, you may also be having issues with containers where they lose their configuration etc after stopping / starting / rebooting the array)

16 hours ago, Squid said:

You've got a docker container referencing on one of its paths /mnt/cache/... and you do not have a pool named "cache" - only a pool named "cache_nvme". Edit each container and update the path appropriately

 

(Because of this, you may also be having issues with containers where they lose their configuration etc after stopping / starting / rebooting the array)

Thank you. I found the issue and resolved it as you stated. No more error...!

FCP gives me the following warning

This is the result of me running syncoid from my main pool to a backup pool. It might be because I am new at ZFS and are doing something I shouldn't or it is an expected result and I can happily press Ignore warning.

Any input would be greatly appreciated. Thank you!

1 hour ago, StefanI said:

FCP gives me the following warning

This is the result of me running syncoid from my main pool to a backup pool. It might be because I am new at ZFS and are doing something I shouldn't or it is an expected result and I can happily press Ignore warning.

Any input would be greatly appreciated. Thank you!

Doesn't that mean that you've got two appdata shares and therefore a ton of duplicated files?  Not the ideal thing to do -> if you reference within the container's template /mnt/user/appdata/... then which pool is it reading from?  There are rules dictating what it does for duplicates, but been forever since I've tested that and can't remember OTOH

Hello, I would like to permanently disable the automatic docker update check. I have stopped using the unraid exclusive docker templates entirely for multiple years now in favour of docker compose.
The Fix Common Problems docker update check is just not working properly for containers not managed by dockerman and basically reports that any "3rd party container" has an update available. This is quite annoying and also makes it harder to see any relevant issues in the reports.

Is there any way to disable the update check in the plugin or could the check be fixed for all containers?

On 1/24/2025 at 4:04 PM, Squid said:

Doesn't that mean that you've got two appdata shares and therefore a ton of duplicated files?  Not the ideal thing to do -> if you reference within the container's template /mnt/user/appdata/... then which pool is it reading from?  There are rules dictating what it does for duplicates, but been forever since I've tested that and can't remember OTOH

Thanks for the answer. You are absolutely right. Appdata became utterly confused. Applications stopped working. Need to clean up the backup pool and figure out how to properly set upp the FS to allow snapshots without this interference.