• 28 June 2010

I met a surprise today. I am writing code that accesses a lot of files via NFSv4, stat()s  them, possibly extracts content and writes stuff into a couple of databases. Somewhen in the debug/development cycle a stat() call returned Resource temporarily unavailable (a.k.a. EAGAIN and EWOULDBLOCK). I tried replacing stat() by lstat() and finally by fstat() in order to assert more control over the flags provided to open(). The combination O_RDONLY | O_SYNC | O_NOATIME changed EAGAIN into EPERM (Operation not permitted). Why is that? Well, here’s a hint.

The O_NOATIME flag was specified, but the effective user ID of the caller did not match the owner of the file and the caller was not privileged (CAP_FOWNER).

Correct. I changed the machine the test ran on. This turned the effective UID into something different (the NFS share showed the numerical 4294967294 which is not the UID of the development account). I’d never have expected this behaviour from the description in the man pages…despite the quoted sentence above…which is really part of man 2 open

RTFM. Again.

Sorry, the comment form is now closed.