I've tried every solution on the Internet but my MariaDb server continue to fail, continue to betray me, continue to destroy my tiny DevOps world. My attempts to smooth the situation included all sorts of satisfaction: changing permissions, configs, removing log files, upgrading / reinstalling, moving her internal files up and around, removing other DBMS, removing everything except her but.... she has never been resisting so much for so long. My last and only hope for you guys to light the way through such critical moment in our relationships.

I'm using vagrant and the problem is in datadir option - when I use default path everything is ok but when I change it to vagrant shared folder Maria does not even start. I have copied all the /var/lib/mysql files to new folder.

I have Windows host, Centos guest and my configurations are:

MariaDb version:

mysql  Ver 15.1 Distrib 10.1.17-MariaDB, for Linux (x86_64) using readline 5.1


# -*- mode: ruby; -*-


Vagrant.configure("2") do |config|
  config.vm.box_url = "https://github.com/tommy-muehle/puppet-vagrant-boxes/releases/download/1.1.0/centos-7.0-x86_64.box"
  config.vm.box = "centos7"

  config.vm.network "private_network", ip: ""

  config.vm.synced_folder "mysql", "/vagrant/mysql", owner: "mysql", group: "mysql"

  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "4096"]
    vb.customize ["modifyvm", :id, "--cpus", "4"]
    vb.customize ["modifyvm", :id, "--hwvirtex", "on"]
    vb.customize ["modifyvm", :id, "--audio", "none"]
    vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
    vb.customize ["modifyvm", :id, "--nictype2", "virtio"]



tmpdir = /tmp

character-set-server = utf8
init-connect="SET NAMES utf8"


key_buffer_size = 32M
max_allowed_packet = 32M
table_open_cache = 8192
table_definition_cache = 8192
sort_buffer_size = 16M
net_buffer_length = 16K
read_buffer_size = 8M
read_rnd_buffer_size = 8M
thread_cache_size = 128
thread_concurrency = 16

query_cache_size = 1024M
query_cache_limit = 2M
join_buffer_size = 32M

max_connections = 1024
max_connect_errors = 1024


innodb_open_files = 1000



MariaDb error log:

2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: The InnoDB memory heap is disabled
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Compressed tables use zlib 1.2.7
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Using Linux native AIO
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Using SSE crc32 instructions
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Completed initialization of buffer pool
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Highest supported file format is Barracuda.
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: 128 rollback segment(s) are active.
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Waiting for purge to start
2016-09-30 22:32:46 139758293125248 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.31-77.0 started; log sequence number 1600799
2016-09-30 22:32:46 139754263774976 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-09-30 22:32:46 139758293125248 [Note] Plugin 'FEEDBACK' is disabled.
2016-09-30 22:32:46 139758293125248 [ERROR] Can't init tc log
2016-09-30 22:32:46 139758293125248 [ERROR] Aborting
  • 1
    Do you have enough space on partition with the log? Can you delete log file and restart?
    – Stoleg
    Commented Oct 4, 2016 at 16:30
  • @Stoleg Hi Stoleg, thank you for reply. There's a lot of free space on partition. I tried deleting the file, restarting and MariaDb creates it and does not start Commented Oct 6, 2016 at 17:07
  • Does account used by Maria, has READ permissions to destination folder? There may be a chance that it can create file with Write, but have no Read permission. Try doing same operations as Maria would do under its account. May be it cannot keep file open and locked?
    – Stoleg
    Commented Oct 10, 2016 at 15:48

8 Answers 8


Woohoo, I found it! For now, at least. Digging through the source suggests that this might have something to do with mmap() calls, and lo and behold - VirtualBox has a bug in that area. Fortunately that same source hints at a workaround - the log_bin option. Enable this (either from the command line as --log_bin or from the config file as log_bin=ON) and things start to work again!


They're saying they've fixed it in VirtualBox 6.0.6!

  • Thank-you so much! This fixed my tc.log error using Virtualbox on a windows 10 host. Commented Apr 1, 2018 at 23:51
  • This seems to have been a significant bit of progress for me also, Windows 10 Home, Docker Toolbox 18.03.
    – rfay
    Commented Apr 16, 2018 at 21:17

I ended up deleting the tc.log file in /var/lib/mysql. When I started mysql again, it created a new tc.log and started up.

sudo rm -f /var/lib/mysql/tc.log
  • 1
    while this feels somewhat unsafe it worked in my case!
    – Peter
    Commented Oct 2, 2018 at 17:32
  • 6
    It worked, but it's safer to use: sudo mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bkp.log Commented Feb 9, 2019 at 22:07
  • 2
    In my case the tc.log was empty (0 bytes) and removing it did the trick. I assume the removal in this case is safe.
    – grizzly
    Commented Oct 18, 2020 at 21:35
  • 2
    Thanks. created a backup copy of tc.log file and delete the original tc.log file worked for me. Commented Feb 19, 2021 at 12:45

You can remove the tc.log in the data directory and remove old entries from mysql-bin.index (it is a text file, along with a list of binary logs). If this is a development box, you can remove the index file (mysql-bin.index) to force its recreation.

Also it could be related to the user ids between mysql user and the shared folder id owner, here is a snippet to do so.

  • Curious about the cause of this issue though, how can I avoid? Thanks
    – 3zzy
    Commented Sep 2, 2017 at 5:06
  • @3zzy - Read my answer.
    – Vilx-
    Commented Sep 4, 2017 at 8:06
  • @3zzy I didn't reproduce the bug yet.
    – 3manuek
    Commented Sep 4, 2017 at 13:15
  • This is a strange issue to encounter indeed. What exactly is stored in this file? I was in such haste to fix the problem I forgot to look at the one that was there. I may be able to provide more detail. Commented May 4, 2018 at 14:53
  • 1
    I suspect that an "out of disk space" error corrupted my tc.log today.
    – jchook
    Commented Aug 2, 2018 at 1:01

If you just want to get mysql/mariadb running again and don't mind losing your data (in a dev environment), this is what I did

Delete: ib_logfile1 ib_logfile0 aria_log_control aria_log.00000001 tc.log ib_data1

start the server

Delete the schema (if it contains files, cd into the schema's folder, delete everything)

I then reimported the database from an old dump I had.

I then started mariadb, and it comes up fine. The deleted files got recreated. ** Again this is for dev only. You could probably install your db**


I also solved this error by removing the tc.log. With XAMPP the tc.log file is in the XAMPP/xamppfiles/var/mysql folder - on my mac its located at: /Applications/XAMPP/xamppfiles/var/mysql/tc.log


I had this issue within MariaDB's official docker container. Removing the log file as the other answers offered did not help me. However, my issue was related to mmap as the accepted answer suggests.

I found various solutions to correct this for my scenario.

  1. Activate Binary Log
  2. Remove the conflict inhibiting mmap from functioning properly

I faced this issue when I tried to copy the database data folder. So I changed to the data folder and executed following command to delete all log files:

rm -rf *log*

Then I rebuilded the docker and issue was sorted.


After I installed MySQL Workbench beside MariaDB 10.x on Ubuntu 19.10.x and suddenly MariaDB was disrupted sudo mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bkp.log worked for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.