Nominate our 2022 Qt Champions!

QSettings on closeEvent and 'setNativeLocks failed: Resource temporarily unavailable'

  • I'm using Redhat 6.6 with Qt5.4.0. Under Qt4 I often put a QSettings call in my MainWindow's closeEvent handler to save window state and geometry. Under Qt5 this seems to be causing issues I don't understand. One issue is that I see 'setNativeLocks failed: Resource temporarily unavailable' output on the console at close. This seems to be preventing some application from exiting cleanly. The following code outputs the string, but does appear to exit properly. I haven't managed to replicate the behavior of my application that doesn't exit in a sample application. On OSX I do not see the issue.


    #include <QtWidgets>
    class MainWindow : public QMainWindow
        virtual void closeEvent(QCloseEvent *e);


    #include "MainWindow.h"
        if (qApp->applicationName().size())
            QString windowTitle = qApp->applicationName();
            if (qApp->applicationVersion().size())
                windowTitle += " " + qApp->applicationVersion();
        QSettings settings;
        restoreState(settings.value("MainWindow/State", saveState()).toByteArray());
        restoreGeometry(settings.value("MainWindow/Geometry", saveGeometry()).toByteArray());
    void MainWindow::closeEvent(QCloseEvent *e)
        QSettings settings;
        settings.setValue("MainWindow/State", saveState());
        settings.setValue("MainWindow/Geometry", saveGeometry());
    int main(int argc, char *argv[])
        QApplication app(argc, argv);
        MainWindow window;;
        return app.exec();

  • @atLeast4Characters

    I'm facing the exact same issue (with CentOS 6.2 and Qt 5.4.1).

    Did you ever manage to solve this?

    Or does anyone else have a solution?

  • Moderators

    Not exactly the same issue but by looking at this thread it might be a case of a stale lock file. Check the /var/lock/ directory as suggested there.

  • Thanks Chris. I tried rebooting the workstation, to no avail.

    Unfortunately, after digging through the Qt bug reports, I found this one which accurately describes the issue:

    QSettings now (5.4+) uses QLockFile and it fails for NFS-connected systems. I'm surprised more people aren't running into this, especially in corporate environments...

  • Well ... someone in a corporate environment here [1] really suffering from this bug after upgrading to openSUSE Leap 42.1 which ships with Plasma 5. Considering openSUSE Leap and SUSE Linux Enterprise Server are now so tightly coupled in development I suspect this bug will start to affect more and more users.

    I would like to add that sometimes it's not just an extra warning, but actually blocks the UI.

    Running strace on kwrite opening a file from a NFSv4 drive results in the following messages:

    open("/NFSv4mount/home/user/.config/kwriterc.lock", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = 9
    fcntl(9, F_SETFD, FD_CLOEXEC) = 0
    flock(9, LOCK_EX|LOCK_NB) = 0
    fcntl(9, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 EAGAIN (Resource temporarily unavailable)
    write(2, "setNativeLocks failed: Resource "..., 56setNativeLocks failed: Resource temporarily unavailable
    ) = 56
    write(9, "24895\nkwrite\nPC-123456\n", 23) = 23
    open("/NFSv4mount/home/user/.config/kwriterc.lock", O_RDONLY|O_CLOEXEC) = 12
    fcntl(12, F_SETFD, FD_CLOEXEC) = 0
    fstat(12, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
    fstat(12, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
    read(12, "29337\nkwrite\nPC-123456\n", 16384) = 23
    read(12, "", 16361) = 0
    close(12) = 0
    uname({sysname="Linux", nodename="PC-123456", ...}) = 0
    kill(29337, SIG_0) = -1 ESRCH (No such process)
    open("/NFSv4mount/home/user/.config/kwriterc.lock", O_WRONLY|O_CLOEXEC) = 12
    fcntl(12, F_SETFD, FD_CLOEXEC) = 0
    flock(12, LOCK_EX|LOCK_NB) = 0
    fcntl(12, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 EAGAIN (Resource temporarily unavailable)
    close(12) = 0
    close(9) = 0
    unlink("/NFSv4mount/home/user/.config/kwriterc.lock") = 0
    nanosleep({6, 400000000}, 0x7ffd3a249730) = 0

    (the nanosleep timer just increases, meanwhile the kwrite window stays "blank" (actually whatever the background of the window was when it was started)).

    If I intervene and remove this file kwrite immediately returns and shows the file. And in subsequent starts the file opens immediately.

    Perhaps a workaround would be to move my .config directory back to local disk and place a symlink in my home folder to this on disk location.

    Relevant bug report:

    My corporate environment, for those interested:
    [1] Using sssd.conf: services = nss, pam, autofs
    Using ldap to login, automount to mount a NFSv4 Kerberized mount.