Unraid 6/Troubleshooting

From unRAID
Revision as of 11:01, 4 January 2020 by Itimpi (talk | contribs) (Capturing Diagnostic Information)
Jump to: navigation, search

Official Documentation Contents List

Troubleshooting

THIS SECTION IS STILL UNDER CONSTRUCTION

A lot more detail still needs to be added

Most of the time Unraid systems function with minimal problems. This section is intended to help with resolving issues that are most commonly encountered.

There are some important general guidelines that it is recommended that a user follows that will help with any troubleshooting that may be required:

  • Use the built-in Help: The Unraid GUI has extensive built in Help for most fields in the GUI. This can be accessed at the individual field level by clicking on the field name, or toggled on/off for the whole page by clicking on the Help icon at the top right of the GUI.
  • Enable Notifications: Unraid has a notification system that can be used to keep you informed about the health of your Unraid system. This can be enabled and the level of notifications you receive tuned under Settings->User Preferences->Notification Settings. Since Unraid systems often function for very long times without needing any user oversight it can be important that you are informed problems when they first occur as if left unresolved they can grow into more serious ones.
  • Proactively fix any reported issues:
  • Ask for help in the forums: Unraid has a vibrant user community and many knowledgeable users who are active in the Unraid forums. Any time you encounter a problem and you are not sure how to proceed it is a good idea to ask questions in the forums. There is nothing worse than rushing into trying to fix a problem using a process you do not understand and as a result making a problem that was initially easy to resolve into something more serious
  • Capture diagnostics: If you want to ask a question in the forums about a problem you are encountering you are frequently going to be asked to provide your system diagnostics file. You need to do so, BEFORE YOU REBOOT so that the logs show went wrong BEFORE the reboot (because once you reboot, it's lost)!

Capturing Diagnostic Information

When you encounter any sort of problem it is always recommended that you attempt to capture as much information as possible to help with pin-pointing the cause. If you want to ask questions in the forum such information will typically be requested as it will speed up the process of getting meaningful and accurate feedback.

System Diagnostics

Unraid has a GUI option under Tools->Diagnostics to capture a lot of information about the state of your system that can be helpful when trying to diagnose any issues. Using this tool will result in a zip file being produced that can be downloaded and then attached to forum posts. If the GUI cannot be accessed for any reason then using the diagnostics command from the Linux level will generate the same information and put the resulting zip file into the logs folder on the flash drive. The Diagnostics should if at all possible be captured BEFORE you reboot so that the lops show what happened leading up to the problem occurring. The zip file produced can then be attached to a forum post when asking for help on a problem in the Unraid forums.

Diagnostics

These system diagnostics include configuration information, state information and key system logs. When creating the diagnostics from the GUI then details of the sort of information that will be included is listed. There is an option (set by default) to say that the diagnostics should be anonymized to try and avoid including any information that might be deemed sensitive. All the files in the diagnostics are text files so a user is free to examine them to check for themselves exactly what information is present.

Note on anonymization of the diagnostics
It has been pointed out that the diagnostics are not completely anonymized if you have enabled mover logging under Settings->Mover Settings as the syslog will give details of files that mover is operating on. This is a bit of a catch-22 scenario as when one has enabled mover logging it is normally to investigate a problem where as much detail as terrible is captured so attempting to anonymize such information may well be counter-productive. Since mover logging is disabled by default and recommended practice is to only have it enabled when investigating why mover is not giving the expected results this is probably acceptable?

Persistent Logs

The main system log is the syslog file and it is the contents of this file that is displayed when you click the Log icon at the top right of the Unraid GUI. Note that when posting to the forums extracted fragments of the syslog are rarely helpful as they do not show what lead up to a problem occurring.

Normally the logs are only written to RAM so do not survive the system being rebooted. If you are investigating a system crash then as long as you are running Unraid 6.7.2 or later you can go to Settings->Network Services->Syslog Server and enable the server

Syslog server
  • Tick the Mirror to Flash option to get a syslog that survives a crash written to the flash drive and is appended to on a reboot. You do not want to leave the Mirror to Flash option ticked if you are not investigating a problem where you cannot get the normal system diagnostics as this can cause a lot of additional writes to the flash drive that can shorten it's lifetime.
  • You can also enter the name or IP address of your Unraid server into the Remote syslog server field and enter a local share where such a file can be stored under the Local syslog folder field. In this case a share set to use the cache drive is recommended to avoid spinning up array drives unnecessarily. This is more appropriate if you wand to continue to keep a permanent copy of the syslog but the file will not be as easy to access if the Unraid system is crashing.

Notes:

  • The standard system diagnostics include the RAM copy of the syslog so there is no need to provide this separately. You will need to do so to provide the logs captured by the syslog server as these are not included in the standard system diagnostics.

Docker Containers

The standard system diagnostics do not contain much that will help with diagnosing issues with specific docker containers.

MORE DETAIL NEEDED

VMs

The standard system diagnostics do not contain much that will help with diagnosing issues with specific VMs.

MORE DETAIL NEEDED


Boot Issues

THIS SECTION IS STILL UNDER CONSTRUCTION'

Preparing the flash drive


Boot Process

Most of the time the Unraid boot process runs seamlessly and the user needs no awareness of the various stages involved. However when things go wrong it can be useful to know how far the boot process managed to get as this will be of use in knowing what remedial action to take.

Resolving boot issues will typically need either a locally attached monitor+keyboard or (if the motherboard supports it) an IPMI connection to carry out equivalent functionality. This can then be used to set any required BIOS stings and to monitor the booting process.

The boot process for Unraid proceeds through a number of stages

  1. Bios boot: This is the stage at which the motherboard BIOS recognizes the presence of the Unraid bootable flash drive and displays the Unraid Boot menu
    • The entries that appear on the boot menu are specified by the syslinux/syslinux.cfg file on the flash drive. Although in theory this file can be edited manually as it a text file it is recommended that it is done via the GUI by clicking on the flash drive on the Main tab and going to the Syslinux configuration section
    • If you want UEFI boot mode to be used then the EFI folder on the flash drive must not have trailing stash.
    • If the user does not select a specific option then after a timeout period the default option will be used. If Unraid is running in headless mode this is the option that will be run.
  2. Linux core: This is the stage at which the syslinux boot loader takes over from the BIOS and starts loading the files specified in the syslinux.cfg file.
    • This is when the core Linux system is loaded from the flash drive and unpacked into RAM.
    • There will be messages on the console about the various bz* types being loaded into RAM.
    • If there are any error messages displayed while loading these files then it normally indicates a problem with the flash drive.
    • There will then be messages displayed as Linux start up and detects the hardware environment.
  3. Flash dependent services: At this stage the flash drive is mounted at /boot so that the process can continue
    • Drivers and configuration information is read into RAM from the flash drive.
    • If the mount of the flash fails it is still possible to get the login prompt displayed. One way to see if this has happened is to login and use the df command. If the flash drive was mounted successfully then you will see it as /boot in the resulting list of mount points.
  4. Plugins: If the user has installed plugins then they are normally loaded at this stage. If one of the Safe Boot options was selected from the Unraid Boot menu then the loading of plugins is suppressed.
  5. Web GUI: The Unraid web GUI is started. It is actually done via an entry in the config/do file on the flash drive so it is possible for user supplied commands to also be run from there ether before starting the web GUI or lest after doing so.
  6. Array
    1. Drives mounted
    2. File Share Services
    3. Dockers Containers
    4. VMs


Shutdown Issues

THIS SECTION IS STILL UNDER CONSTRUCTION


Crash Issues

THIS SECTION IS STILL UNDER CONSTRUCTION


Data Recovery

THIS SECTION IS STILL UNDER CONSTRUCTION

A lot more detail still needs to be added

This section is about recovering your data when Unraid reports problems with one or more drives.

There are some important points to bear in mind about securing your data(

  • Backup critical data: Unraid will protect you against most types of simple hardware failure, but not catastrophic failure. You should ALWAYS have backups of any critical data that you cannot afford to lose. Ideally one of those copies should be offsite or on the cloud to protect yourself against unforeseen issues such as fire, theft, flood, etc.
    • Each user has to make their own determination of what they deem critical and make an assessment of the level of risk they are prepared to take.
    • Personal data such as photographs & documents tend to always be deemed critical. Luckily these tend to be relatively small so easy to back up.
    • Media files are often deemed non-critical and are relatively large so a user may well decide these do not merit being backed up
    • Personal video that can never be replaced should fall into the critical category regardless of it's size
    • Remember that there are things such as ransomware around so there should be at least one copy of critical files that cannot be accessed online and corrupted if you are unfortunate enough to suffer from such an attack!
  • Be pro-active about resolving any issues that are detected by Unraid. Make sure that notifications are enabled under Settings->Notifications so that you get told as soon as issues are detected. For many users Unraid operates in a fire-and-forget mode so that they will not be actively checking for problems so need such reminders.
  • Ask for Advice:
    • The Unraid forums have lots of knowledgeable users who can help guide you through what needs doing to get your data back into a standard if you are not sure what are the best steps to take.
    • Unraid is very good about protecting your data against typical hardware failures , but it is not immune against users taking inappropriate steps to recover their data after a failure occurs.