At work we use CIFS to mount some folders of our NAS into Linux servers. Since some days we had real problems using the Typo3 extension manager: Whenever we tried to install an extension, we got "Operation not permitted" and "No permission" errors when the install tool tried to create folders and chmod them.
I wrote a small php script which reproduced the problem:
- Create a folder
- Change the permissions of that folder
- Create a subfolder
- Change permissions on that subfolder
While creating the folder worked, neither changing permissions nor creating the subfolder did. The same script ran fine on an NFS mount, though - so it wasn't a server problem. File and directory permissions all were ok.
After some experimenation I found out that inserting a sleep(1); call fixed the problem, and that I could go down to 900ms using usleep();. A colleague explained to me that this was most likely be a caching issue: CIFS caches inode data, and by not clearing the cache after creating a directory, it still sees the folder as non-existing - resulting in a "operation not permitted" error. The 1 second sleep fixed that.
$searchengine delivered some results about using forcedirectio or directio mount options, the mount.cifs man page told me to use direct. Nothing helped.
The solution came to me when scrolling though /usr/src/linux/fs/cifs/README:
LookupCacheEnable If set to one, inode information is kept cached for one second improving performance of lookups (default 1)
A echo "0" > /proc/fs/cifs/LookupCacheEnable did the trick.
Update a day later
forcedirectio or one of the other two aliases did actually do something! When I came into office this morning, I had 500 mails of cronjob errors, all with the same message:
Failed loading /usr/local/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so: /usr/local/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so: failed to map segment from shared object: No such device
Further, strace revealed:
mmap2(NULL, 208004, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = -1 ENODEV (No such device)
Mark Karpeles of #php.pecl gave me the hint I needed: man mmap tells us:
ENODEV The underlying filesystem of the specified file does not support memory mapping.
And that was it. After disabling the three *direct* options in fstab, it worked.