Jump to content

Squid

Community Developer
  • Posts

    28,733
  • Joined

  • Last visited

  • Days Won

    314

Everything posted by Squid

  1. Did you actually see that message in the banner??? Update all plugins. Make a backup of the flash drive. Then upgrade
  2. About the only thing which would be to remove any excess folders from /config/plugins that are from plugins which no longer installed. Realistically though, most plugins would automatically remove their directories (or should). However, there are also "system" folders (eg: dockerMan) which cannot be removed To get rid of excess templates for docker containers, go to Apps, Previous Apps and delete (check off and then delete) the ones which you are no longer / have no need for anymore
  3. Remove the mover tuning plugin and it should work then repost your diagnostics into it's support thread
  4. Disable any and all browser extensions and try again
  5. What I'd try. In Settings, Network Settings disable bonding and bridging. No need for it since you've only got the single NIC After that, try creating a new docker.img (Settings - Docker - Disable the Service). Give it a different name than docker.img so that we can revert back if necessary. Then try reinstalling your apps from Apps, Previous Apps
  6. Nov 24 04:45:25 Unraid kernel: BTRFS info (device sdc1: state E): forced readonly Wait for @JorgeB to look at this and advise. He's the resident Uber Expert par none around here
  7. 1 - We always need diagnostics (preferably grabbed while this is happening) 2 - If anyone in a position to fix the problem could ever replicate it, then it would be fixed.
  8. Does at least the navigation bar / header show up? Reboot into safe mode
  9. What's not reliable about it? It works. Only "issue" (and it's not an issue if you really think about what's going on under the hood) is if you attempt to pin containers to multiple isolated cores. Since you're not running any VMs, doubtful you've got any isolated cores
  10. Looks like CT500MX500SSD1_2303E69FAF02-2023-07-14 cache2 (sdj) dropped offline / dropped dead. Check the cabling
  11. As previously mentioned, today's release of CA brings it minimum requirements for the OS to now be 6.12.0. This is mainly because of the necessity to test, add in compatibility code etc for a number of other fixes contained within this release for OS versions 6.9 - 6.11. TBH its not worth my time and effort (realistically this takes days full time to do) to support deprecated versions of the OS. (And its already enough of a PITA to test back to 6.12.x when I run 6.13 on my systems) Big fix here is regarding AC creating orphans when performing multiple upgrades. You should check Docker (Advanced View) and delete any orphans which are present)
  12. Support can resend you your license key if you show them a copy and paste (no screenshots) of what appears within Tools - Registration
  13. Only support can look into GUID issues
  14. monitor is a built-in script and runs every minute. You should create a new thread and include your diagnostics
  15. Known issue with the current release of Apps and performing multiple upgrades at a time. Fixed for next release (soon), but you container is updated... An orphan however will get created which you can delete via Docker, Advanced View
  16. Can you also attach the complete diagnostics.zip file (not the commands that were run) here.
  17. Can you try it again but removing these lines from your "go" file (/config/go on the flash drive) that you've added: # Add these lines to the end of the file #echo 'export DOCKER_OPTS="--default-ulimit nofile=1024:2048 --default-timeout=999999999"' >> /boot/config/go export DOCKER_OPTS="--default-timeout=999999999" Can you also try removing compose manager to see if it's interfering
  18. You're being spammed by Nov 6 18:37:54 Odin kernel: .NET ThreadPool[15562]: segfault at 14 ip 000014a9b05b33e0 sp 000014a9914f26a0 error 4 in libSkiaSharp.so[14a9b0200000+8d7000] Nov 6 18:37:54 Odin kernel: Code: 50 49 89 fe 8b 47 24 3d ca 00 00 00 74 15 49 8b 0e c7 41 28 14 00 00 00 89 41 2c 49 8b 06 4c 89 f7 ff 10 49 8b 86 20 02 00 00 <83> 78 14 00 0f 84 91 00 00 00 49 8b 46 30 49 89 86 88 00 00 00 49 Not sure which docker container this is coming from though. But it would be prudent to run memtest from the boot menu for at least a couple of passes to see if you have bad memory
  19. Those diagnostics show that docker isn't running... Do you have the same issues if you enable docker? (Settings, Docker)
  20. Time Machine has been a bit of a project in sorting this all out You must give the time machine share a volume size limit. Leaving it empty does not work anymore You should always specify a single disk on the included disks section when creating the share. Time Machine backups via SMB are stored as a single vdisk. This means that it is constrained to a single disk no matter what. Depending upon how your split levels work etc and how much free space you have on whatever disk it winds up creating the share on, you could have significantly less space available than you think. If the volume size limit is greater than the available space on the drive, then TM will work for a little bit (days) and then ultimately fail Anecdotal Any failed backup for whatever reason to a SMB share will result in TM never being able to backup again to that share without deleting the share and then re-creating it (and having TM re-initialize the backup) Any change to SMB settings after creating the share seem to need a restart of Unraid. (eg: creating a new share etc) At the end of the day, TM to network drives is unsupported by Apple (although it lets you do it). Findings / fixes are still a work in progress for me.
  21. Without seeing the docker run command, what you're seeing is probably to be expected (and will happen on any OS -> not just Krusader / Unraid) Presumably, you've mapped something like /mnt or /mnt/user to /Unraid Shares What every OS in the world attempts to do is that when you're accessing everything from a single mount point, it will do a rename instead of a copy / delete to move the file. Because the rename succeeds, effectively the file is still on the same drive. Windows works in this case because you're accessing each share from a different mount point (each share that appears within windows is a different mount). Because the source and destination are different mount points Windows has to do a copy / delete since a rename will automatically fail. Probably the best thing to do here is either continue to use Windows for this type of operation or try Dynamix File Manager instead, or set up the shares so that they will move to the array, or work with /mnt/diskX exclusively within Krusader (do not mix copying / moving with /mnt/diskX and /mnt/user )
  22. Watching the video how? Plex? Transcoding?
  23. 5.5MB/s is not normal. Post diagnostics again while its in this state
  24. Have you run a memtest from the boot menu? It would also be helpful for you to enable the syslog server (mirror to flash) and after the next crash (your system is crashing, not sleeping) to reply back with the syslog file stored within /logs on the flash drive
×
×
  • Create New...