This problem comes from a downstream bug report:

https://bugs.mageia.org/show_bug.cgi?id=5337


Basically the problem is that the user in question as an encrypted partition which he unlocks during his user login. If the partition is unlocked when colord starts, the fact that colord is running actually prevents him from running luksClose with a "Device or Resource Busy" (note that the encrypted drive is already unmounted by this stage, it's purely the "tidying up" of the encrypted volume that's failing).

Killing colord allows the operation to succeed.

Note this only happens if colord is started *after* the partition is unlocked (i.e. dbus activated by the user login). If it's started earlier (either manually or by a different (i.e. test) user logging in first before the encrypted partition is unlocked) then there is no problem.


Now I'm pretty certainly that colord itself is not playing with /dev/mapper/* or /dev/dm* stuff, but perhaps it's doing something that could interfere somehow? I don't know, maybe inotify stuff that somehow misbehaves or some external library that is doing weird things? Figured you'd be the best person to ask for advice at the very least! I did have a quick scan through the code, but nothing jumped out at me.

Note that cupsd also seems to be doing similar things, so this could have the same root cause, or simply have similar problems.