What I want to do

Build my yum/dnf repository on a cifs share.

Long version

My windows server is my main file server, and I store my Support/Platforms/Korora22/ directory there for the time being. I have my rpms there, some downloaded and some self-rolled.

I want to host a repository there, but my createrepo . command throws back this error:

[root@linux-05|/mnt/smash/Support/Platforms/Korora22]# createrepo .
Spawning worker 0 with 3 pkgs
Spawning worker 1 with 3 pkgs
Spawning worker 2 with 2 pkgs
Spawning worker 3 with 2 pkgs
Workers Finished
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs

(process:368): GLib-CRITICAL **: g_timer_stop: assertion 'timer != NULL' failed

(process:368): GLib-CRITICAL **: g_timer_destroy: assertion 'timer != NULL' failed
Traceback (most recent call last):
  File "/usr/share/createrepo/genpkgmetadata.py", line 308, in <module>
  File "/usr/share/createrepo/genpkgmetadata.py", line 280, in main
  File "/usr/lib/python2.7/site-packages/createrepo/__init__.py", line 1005, in doRepoMetadata
    rp.getOtherdata(complete_path, csum)
  File "/usr/lib64/python2.7/site-packages/sqlitecachec.py", line 61, in getOtherdata
TypeError: Can not create db_info table: database is locked



Steps I've already tried that did not help

rm -rf /var/lib/rpm/__db*
rpm --rebuilddb

dnf clean all

My /etc/fstab includes this line:

//win-server1/smash       /mnt/smash        cifs     rw,user,uid=bgstack,credentials=/root/.bgstack.example.com,exec,soft

Observe that it will mount my directory as the user bgstack, so I actually umounted and mounted with uid root (effectively, by leaving that part out):

mount -t cifs -o credentials=/root/.bgstack.example.com //win-server1/smash /mnt/smash

It still would not successfully complete a createrepo command.

What appeared to work but is not optimal

This works, but is very clunky.

Host all rpms locally and create the repository there. Then transfer the repo data to the cifs share.

# as root: createrepo does not like regular users
mkdir -p ~/localrepo
cp -pr /mnt/smash/Support/Platforms/Korora22/*rpm ~/localrepo
createrepo ~/localrepo
cp -pr ~/localrepo/repodata /mnt/smash/Support/Platforms/Korora22/
  • did you ever find a resolution to this?
    – beeks
    Apr 19, 2016 at 14:58

1 Answer 1


I ran into this problem, and it appears some others are as well. The common factor, is that our repository directories are mounted on a CIFS share with RW access.

Per this RedHat BugZilla: https://bugzilla.redhat.com/show_bug.cgi?id=429201

What worked for me was modifying my /etc/fstab/ file to include nobrl in my CIFS declaration:

# /etc/fstab
# Created by anaconda on Mon Apr 18 15:04:59 2016
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
/dev/mapper/centos-root /                       xfs     defaults        0 0
UUID=a15ce235-0cd8-4890-95ed-9f1f8803e1fc /boot                   xfs     defaults        0 0
/dev/mapper/centos-swap swap                    swap    defaults        0 0
\\\\QNAP\\repo /repo cifs nobrl,rw,file_mode=0777,dir_mode=0775,async,noperm,credentials=/root/creds_smb_library_core,uid=5000,gid=6000 0 0

After performing a reboot confirm that the filesystem is mounted from a cold boot, createrepo worked fine.

The nobrl option removes Byte Range Locks from being applied against the mounted filesystem, which allows createrepo to successfully update/access the SQLite database without attempting and failing to achieve a lock.

  • Excellent discovery! I was able to accomplish this task without rebooting by unmounting and remounting the drive.
    – bgStack15
    Apr 21, 2016 at 12:05
  • @bgStack15, Thanks! Yea, that might have worked without a reboot. I know many like to achieve everything without rebooting in Linux, but is that ever a good test to confirm that everything is going to come up after an unexpected reboot?
    – beeks
    Apr 21, 2016 at 14:30
  • By adding the filesystem with nobrl attribute to the /etc/fstab file, the mount /repo command will mount exactly the same as how it does upon booting. So I'd say yes, it's a good test. If you have an unexpected boot, you should check other things in addition to this filesystem.
    – bgStack15
    Apr 21, 2016 at 15:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .