Jump to content

itimpi

Moderators
  • Posts

    20,789
  • Joined

  • Last visited

  • Days Won

    57

Everything posted by itimpi

  1. Not at the moment with the current 6.12.x releases although typically pool performance is sufficient not to need it being fronted by a cache drive.
  2. As was mentioned you need to get a syslog that proceeds the restart to have any information about what was happening at the time and that can only be achieved if you have the syslog server capturing a persistent syslog at the time of the crash.
  3. You can manually upgrade or downgrade to any Unraid release for which you have the zip file version of the release as described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The 6.12.4 release is still available for download from the Unraid site.
  4. The problem is that the diagnostics only show what has happened since the last time the server was booted so often is insufficient (although it can contain clues).
  5. Those errors are saying that your ‘cache’ pool is corrupt and needs fixing. Since that is where everything docker related seems to be not surprising you have issues. btrfs corruption seems to be most commonly related to ram issues, so have you run a memtest recently?
  6. You are getting continual resets on the parity drive. It looks like it could just be an issue with the power and/or SATA cabling to that drive so it could be worth checking that and retrying the rebuild.
  7. not quite enough. As set then the server is listening for other systems to send it messages to log. To get the server to log its own syslog messages you need to set one of the last two fields as described in the syslog server link or the built-in help.
  8. Unraid has a custom md driver that works at the block level for array drives below any file system so is file system agnostic. Unraid has no automatic file integrity checks that covers all file systems supported, but if you use a file system such as btrfs or ZFS which does have such checks then you get them for the drives using those file system types.
  9. Your syslog in the diagnostics has: XFS (md1p1): corrupt dinode 1073741953, (btree extents). Dec 22 13:27:45 Tower kernel: XFS (md1p1): Metadata corruption detected at xfs_iread_bmbt_block+0x76/0x1dd [xfs], inode 0x40000081 xfs_iread_bmbt_block Dec 22 13:27:45 Tower kernel: XFS (md1p1): Unmount and run xfs_repair so at very least you need to run a check filesystem on disk1 as file system corruption can stop shares showing up as expected. It would not do any harm to also do the other drives just in case.
  10. That is not the process you should follow according to the online documentation.
  11. That currently seems to be an unavoidable issue when trying to use that script.
  12. You need to run the SMART Extended test to properly test the drive - the Short test is often insufficient in finding errors.
  13. You could try this process as it often fixes issues reading from the flash drive. In terms of settings they are all stored on the flash drive in the 'config' folder. You should see if you can make a copy of that while on a PC/Mac trying the process mentioned above.
  14. Tools->New Config. That tool is mentioned here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release.
  15. The diagnostics are mostly empty which suggest the flash drive was not online at the time they were taken. This is also suggested by the fact that they had 'tower' in the name which is consistent with Unraid losing access to its settings.
  16. You can always manually upgrade/downgrade manually as described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.
  17. Have you tried running Tools->New Permissions against the relevant share? The other thing would be to run a check filesystem on all drives as sometimes filesystem corruption can stop shares showing all their content correctly.
  18. Something seems to have filled up the /var/log folder. It might be worth running a command like: du -sch /var/log/* To see if you can spit what it is.
  19. Have you tried removing the docker folder plugin that is not compatible with this release of Unraid?
  20. I know the release notes suggest it should be there, but it appears it is not. I was going by this post
  21. I think I read that it is going to be either in 6.12.7 (if it appears) or 6.13
  22. I notice that the 'appdata' share has files on both the 'cache' and 'appdata' pools - this seems strange. You might get a clue why mover is not doing what you expect if you turn on mover logging. Mover will never overwrite an existing file so if you have somehow ended up with duplicate files on more than one drive it is a manual task to decide which copy to keep and delete the other one.
  23. Looks like the system is having problems with one of the drives: Dec 21 13:18:37 Tower kernel: ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80) Presumably this is the 'missing' drive. Probably need to carefully check the power and sata cabling to the drive.
×
×
  • Create New...