Help Center Help Articles Professional Support Community RMA & Warranty Downloads Tech Specs

UniFi - Repairing Database Issues on the UniFi Network Application

Use this article to repair the database of malfunctioning UniFi Network applications. Please note this only applies to users self-hosting the latest version of UniFi Network Server on their own Windows/macOS/Linux machine. Legacy (Gen 1).

Users running the UniFi Network application in a legacy way (Vintage CloudKey Gen 1, or a 32-bit based UniFi Network Server) can find information in the last section of the article. These are no longer supported, and we generally recommend upgrading to the latest version of the UniFi Network application, or adding UniFi Console for the easiest experience with effortless scalability.

Symptoms

  • Statistics are only recorded for a few days and then are cut off or are only intermittently available.
  • Backups including statistics data cannot be generated.
  • Settings-only backups cannot complete, or are created but are unable to be restored due to corruption.
  • An error 400 is generated when trying to open UniFi Network.
  • The UniFi Network application service will not start due to database errors.

Repairing a Debian-based Linux Database

  1. Stop the UniFi service
    service unifi stop
  2. In some cases, where the journal is corrupted, it will be helpful to run the following command before repairing the database, to move it to another location:
    mv -vi /usr/lib/unifi/data/db/journal /usr/lib/unifi/data/db/journal-$(date -I)
  3. Repair the database with this command:
    mongod --dbpath /usr/lib/unifi/data/db --logpath /usr/lib/unifi/logs/mongod.log --repair
  4. Finally, restart the UniFi service:
    service unifi start
    1. Note: If this process was performed as root the file ownership may have changed. This can be changed with:
      chown -R unifi:unifi /usr/lib/unifi/data/db/
      chown -R unifi:unifi /usr/lib/unifi/logs/

If you still have suspected database issues please migrate to a CloudKey Gen2 Plus or Dream Machine Pro. These UniFi Consoles do not experience this type of database corruption.

Repairing a macOS Database

  1. Create a temporary working directory. For repair purposes, we will call this directory /repair. In terminal:
    mkdir ~/repair
  2. Visit the MongoDB official download website, and download the .tgz release that corresponds to your server's CPU architecture.
    1. You can also download 2.4.14 here directly: 2.4.14.tgz
  3. Move the downloaded package to your working directory, and extract it by double-clicking it or using the application of your choice.
  4. Locate the bin/mongo binary file, and copy it to your working directory.  At this point, the downloaded .tgz package and any extra extracted files can be deleted as we only need the mongo binary.
  5. Open Terminal and move to your working directory:
    cd ~/repair
  6. Close or stop UniFi.
  7. Repair the database with this command:
    mongod --dbpath ~/Library/Application\ Support/UniFi/data/db --logpath ~/Library/Application\ Support/UniFi/logs/mongod.log --repair
  8. Open the UniFi application from Finder:
    open -n /Applications/UniFi.app

If you still have suspected database issues please migrate to a CloudKey Gen2 Plus or Dream Machine Pro. These UniFi Consoles do not experience this type of database corruption.

Repairing a Windows Database

  1. Visit the MongoDB official download website, and download the .zip release that corresponds to your CPU architecture.
    1. Note: The minimum MongoDB version required is 3.6, and the maximum is 4.4.
  2. Extract \bin\mongod.exe to a working directory of your choice.  In this example, we will use C:\repair\ You may ignore all other files included in the .zip.
  3. Close or stop UniFi.
  4. Open the command prompt by pressing WINDOWS + R.  In the popup, type cmd, and press ENTER.
  5. Enter Working Directory:
    cd C:\repair\
  6. Repair the database with this command:
    mongod.exe --dbpath "%userprofile%\Ubiquiti UniFi\data\db" --logpath "%programfiles%\Ubiquiti UniFi\logs\mongod.log" –repair
  7. Open the UniFi application.

If you still have suspected database issues please migrate to a CloudKey Gen2 Plus or Dream Machine Pro. These UniFi Consoles do not experience this type of database corruption.

Legacy Instructions

32-bit MongoDB limitations

32-bit MongoDB collections are limited to a total size of 2GB. While running the MMAPv1 storage engine this can cause issues when trying to shrink the aggregate collection sizes. When running a compact command on the MongoDB, the database is rewritten and defragmented without error correction. This process does not return usable disk space to the UniFi Console when the storage engine is MMAPv1.

Getting back that valuable disk space on a 32-bit MongoDB instance will require a repair of the database. This repair may be needed for those who are suspecting invalid entries, corruption, or collection scaling issues. To be able to run a database repair, the CloudKey will have to have enough free disk space equal to the size of the current data set plus 2 gigabytes. If the dataset has already grown too large to proceed with the db.repairDatabase() command there are instructions below to work around that.

Note: The Legacy CloudKey (UC CK) utilizes the following:

  • 32-Bit architecture
  • MMAPv1
  • MongoDB Version 2.4.10
Repairing a Vintage CloudKey (Gen 1) Database
  1. Establish an SSH connection with the CloudKey.
  2. Download the mongo pruning script. As written, the script will only keep entries from the past 7 days. It will not remove entries that are required for UniFi administration. Do so by running the following command:
    cd /tmp/
        wget https://help.ui.com/hc/en-us/article_attachments/360008640574/CK_repair.js
  3. Stop the UniFi service:
    service unifi stop
  4. The UniFi service will shut down the mongo process. Make sure that the UniFi service has been completely shut down. Repair the database to compact the data entries and free unused disk space field that is included in the query criteria.
    mongod --dbpath /usr/lib/unifi/data/db --logpath /usr/lib/unifi/logs/server.log --repair
    1. NOTE: Steps 5-8 are optional if you need to prune back the database to conserve disk space.
  5. Restart mongo using:
    mongod --dbpath /usr/lib/unifi/data/db --logpath /usr/lib/unifi/logs/server.log --journal --bind_ip 127.0.0.1 --fork
    1. NOTE: Journaling may not be have been enabled in your mongo database. If so, then remove the --journal option in the above command.
  6. Execute the script to prune the stat collections that are causing the problem:
    mongo < /tmp/CK_repair.js
  7. Shut down the mongo server with this command:
    mongod --dbpath /usr/lib/unifi/data/db --logpath /usr/lib/unifi/logs/server.log --shutdown
    1. Note: The last command in the CK_repair.js script is "db.repairDatabase()". It may result in an error if the stats collections have already grown too large to be repaired while the mongo server is running. If you see such an error running the script then you will need to repair the database from the command line once again by running the command in step 3.
  8. Finally, restart the UniFi service:
    service unifi start

The CloudKey should now be able to run the Network application. If you still have database issues, please upgrade to the latest CloudKey Gen2 Plus which does not experience this problem.

Migrate from MMAPv1 to WiredTiger

Attention: This section does not apply to 32-bit architecture consoles including the UC-CK G1.

After UniFi Network is functional again, a user may wish to migrate it to the WiredTiger storage engine.

To verify how much space is used, run the following command:

du -shc /usr/lib/unifi/data/db/ace* /usr/lib/unifi/data/db/journal/* /usr/lib/unifi/data/db/local* | grep total

To verify which MongoDB version is being used, run the following:

mongod --version | grep "db version"

To verify what storage engine version is being used, run the following two commands:

mongo localhost:27117
    db.serverStatus().storageEngine.name

How to Migrate to WiredTiger

  1. Create a backup under Settings > Maintenance > Backup with the desired retention settings.
  2. Uninstall UniFi from Windows or macOS. Purge UniFi from Debian-based Linux with the command:
    sudo dpkg -P unifi
  3. Reinstall UniFi on Windows or macOS. Reinstall UniFi on Debian-based Linux with the commands:
    cd /tmp/
    wget <https link to download>
    sudo dpkg -i unifi_sysvinit_all.deb
  4. In the UniFi Setup Wizard restore the backup from step 1.
Was this article helpful?
97 out of 289 found this helpful