4 hours ago, Squid said:

Either you're running a script which is creating a share named boot (/mnt/user/boot) or a path mapping on one of your docker containers has a path mapping of /mnt/user/boot

 

Whenever that script runs or the container starts it will recreate it

Thanks I did check the docker paths to make sure, as well as the shares tab.  dont see anything referring to boot.  Ive had it for a long time.  

 

Not sure if it helps, but when I run 'smbclient -L localhost'  it doesnt list it

 

Is there a way to find where the share is located so I can disable it?

 

     Sharename       Type      Comment
        ---------       ----      -------
        3D Printing     Disk      
        Apps            Disk      Applications
        Backups         Disk      Backups
        Games           Disk      Games
        HI***     Disk      
        Home            Disk      Home Directories
        Music           Disk      
        Pictures        Disk      
        Public          Disk      Public
        Scratch         Disk      Scatch SSD
        T***     Disk      
        V***           Disk  
        V***     Disk      
        appdata         Disk      
        clients         Disk      
        docker          Disk      
        eBooks          Disk      
        isos            Disk      ISO images
        IPC$            IPC       IPC Service (Media server)

ls -ail /mnt/user

It'll be listed.

6 minutes ago, Squid said:

ls -ail /mnt/user

It'll be listed.

Thanks, I see it.

 

653866390226207098 drwxrwxrwx   1 nobody   users        4096 Dec 31  1969 boot/

 

looks like its looking at the boot flash drive.  I looked at the flash settings, and it had flash as the smb share, which i disabled as I dont need it shared. 

 

is it safe to delete from /mnt/user? I assume that will delete it from the flash drive.  I am assuming there is a link somewhere to it/

 

 

 

Something (odds on a container) is creating it.  There are no symlinks or anything that puts boot into a user share.  The date however is weird.  You can always browse through the share via the shares tab to see whats in there.

6 minutes ago, Squid said:

Something (odds on a container) is creating it.  There are no symlinks or anything that puts boot into a user share.  The date however is weird.  You can always browse through the share via the shares tab to see whats in there.

Thanks. I will double check all the docker containers again.  I do not have 'boot' in the shares tab.  When I go to command line, and go to /mnt/user/boot. it looks like it lists whats on the flash drive. I will had to recheck and look at both to verify as I just quickly glanced.  Modified dates were recent.  Really appreciate your help. 

I have a suggestion for Fix common problems upgrade assistant. I read in another thread somewhere that there's a XFS programs update or similar between 6.9.x and 6.10/11.x, which caused some folks arrays not to mount due to some minor forms of corruption. I wonder if a XFS check could be run across array drives by upgrade assistant (or even just by fix common problems) to make sure this isn't an issue.

I would suggest ignoring the Jumbo frames MTU issue if the NIC is 10Gbps and not eth0. I would think its a pretty common use case to have a gigabit NIC for Internet access and 10Gbit for local LAN network.

 

My only other feature suggestion is to add white space between the error/warning sections and the ignored sections for improved visual reading.

17 hours ago, CaptainMorganCrunch said:

I would suggest ignoring the Jumbo frames MTU issue if the NIC is 10Gbps and not eth0. I would think its a pretty common use case to have a gigabit NIC for Internet access and 10Gbit for local LAN network.

 

Fix Common Problems attemps to highlight common problems that trip people up. It is true that there can be valid setups for jumbo frames, but there is no way for FCP to validate you have properly setup every device on the second network to work with jumbo frames. So we issue a warning and if you are sure you have things setup correctly you can just click ignore.

 

In general though, we recommend avoiding jumbo frames:

https://forums.unraid.net/topic/120220-fix-common-problems-more-information/page/2/#comment-1167702

 

On 11/6/2022 at 10:49 AM, voidpointer said:

The "Fix Common Problems" plugin warns about updating every individual docker container:

 

> Docker Application prowlarr has an update available for it

 

How can I disable this permanently for *all* docker containers?

Anyone?

1 hour ago, voidpointer said:

Anyone?

There isn’t an option for *all. You just need to click ignore for each one though.

Hi there, im getting the issue of directory bread errors found. unraid starts fine without any issue. I have tried file check without issue. I can only assume that my usb stick drops offline and then reconnected itself. cable is ok as i wont be getting this issue. I have got my diagnostic file.

hammerthread-diagnostics-20221122-1137.zip

Try a different port.  If that fails, then replace the flash drive.  You'll also have to reboot

Can anyone tell me how to resolve this error?  It showed up after I had to do a hard restart due to my server becoming unresponsive during a parity check (seperate issue).

 

/boot/config/shares/appdata.cfg corrupted  -  Your flash drive has possible corruption on /boot/config/shares/appdata.cfg. Post your diagnostics in the forum for more assistance 

arptimbers-diagnostics-20221127-0743.zip

There doesn't appear to be any obvious corruption on that file.  Did you try hitting "rescan" within FCP?

Possible Hack Attempt on Nov 21    On Nov 21 there were 61 invalid login attempts. This could either be yourself attempting to login to your server (SSH / Telnet) with the wrong user or password, or you could be actively be the victim of hack attacks. A common cause of this would be placing your server within your routers DMZ, or improperly forwarding ports.
This is a major issue and needs to be addressed IMMEDIATELY
NOTE: Because this check is done against the logged entries in the syslog, the only way to clear it is to either increase the number of allowed invalid logins per day (if determined that it is not a hack attempt) or to reset your server. It is not recommended under any circumstance to ignore this error  More Information    

 

i do not allow access to my server from the outside so i am not sure how this is happening. i have been running unraid for a few years and have had little to no issues with it which is good because i am not overly compitent with it. Any suggestions would be great.

thanks Desiel
 

plexserver-diagnostics-20221128-0921.zip

On 11/27/2022 at 9:01 AM, Squid said:

There doesn't appear to be any obvious corruption on that file.  Did you try hitting "rescan" within FCP?

Yes, it seems to be resolved now.  Either simply by rescanning, or with this most recent Unraid OS update.  Thank you for the response.

8 hours ago, desiel said:

i do not allow access to my server from the outside so i am not sure how this is happening. i have been running unraid for a few years and have had little to no issues with it which is good because i am not overly compitent with it. Any suggestions would be great.

thanks Desie

Nov 21 16:43:47 plexserver sshd[20945]: Connection from 192.168.1.71 port 52849 on 192.168.1.76 port 22 rdomain ""
Nov 21 16:43:47 plexserver sshd[20945]: Invalid user admin from 192.168.1.71 port 52849

There're all from your local network.  What is that IP address?

12 hours ago, Squid said:

Nov 21 16:43:47 plexserver sshd[20945]: Connection from 192.168.1.71 port 52849 on 192.168.1.76 port 22 rdomain ""
Nov 21 16:43:47 plexserver sshd[20945]: Invalid user admin from 192.168.1.71 port 52849

There're all from your local network.  What is that IP address?

its my desk top. i also found out my grand child was on the computer so i am just guessing but i think i know the issue. thanks for having a look.

desiel

So im getting a warning from CA-FCP saying: /boot/config/smart-one_.cfg corrupted

Your flash drive has possible corruption on /boot/config/smart-one_.cfg.

 

Please advise what i should do, or if this is a false positive.

 

Thanks.

lupus-diagnostics-20221205-1416.zip

4 hours ago, Natcoso9955 said:

smart-one_.cfg

Delete this file, it's not needed anyway, the one used is smart-one.cfg

21 minutes ago, JorgeB said:

Delete this file, it's not needed anyway, the one used is smart-one.cfg

I thought this was the case, but since i didnt know what the file did, didnt want to break anything. haha

On 11/4/2022 at 5:05 AM, Squid said:

It appears to be a semi-standard Ryzen mce that is completely benign and nothing to worry about

 

Why is it that it seems to cause reboots whenever it happens. Is there a way to prevent this?

Hey,

the FCP plugin gives me a warning, that two NICs (eth 1 and eth 2) are having the same ip address, but there is only eth 1 visible in the network settings. Everything is working fine. 

Does anybody know how to fix this?

 

Greetings

Michael

tower-diagnostics-20221207-1818.zip

On 11/6/2022 at 4:49 PM, voidpointer said:

The "Fix Common Problems" plugin warns about updating every individual docker container:

 

> Docker Application prowlarr has an update available for it

 

How can I disable this permanently for *all* docker containers?

 

On 10/26/2022 at 12:50 AM, bdr9 said:

This plugin is reporting many warnings on my Unraid server, but they are all Docker container updates. I can ignore them individually, but that only ignores the one specific Docker container, and warnings are still generated for other Docker containers. I would prefer not to receive any warnings for Docker container updates. Is there a way to disable this entire category of warning?

 

This is a very long thread but I can only find issue reports and not a fix.

 

How do I disable the image update warning entirely? I find myself starting to ignore Fix Common Problems because 99/100 it is docker noise and that cant be a good thing when that one time is important.

You don't.  Warnings have to be ignored on a case by case basis.  After you ignore it once, it should never appear again.