Home » Php » linux – PHP scandir() fails on cifs mount until php-fpm restart

linux – PHP scandir() fails on cifs mount until php-fpm restart

Posted by: admin July 12, 2020 Leave a comment


The below setup works as well as expected for awhile. Eventually, the CIFS host goes offline (patches, power, etc). When that happens… PHP appears to lose it’s mind and Refuses to access files in the mount point until php-fpm is restarted despite the CIFS share being entirely accessible by the OS.

Warning: scandir(repository/Some Series/Some Title): failed to open dir: No such file or directory in /var/www/audiobooks/libraries/bookScan.php on line 169

Any pointers on what I am missing, so as to not require a php-fpm restart?

I have the following mount point on a linux server:

//10.68.x.x/Media/Audiobooks on /var/www/audiobooks/repository type cifs (rw,relatime,vers=default,cache=strict,username=xxxxxx,domain=/,uid=48,forceuid,gid=996,forcegid,addr=10.68.x.x,file_mode=0755,dir_mode=0775,soft,nounix,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

The following code is run:

public function getBookFiles($book)
$path = $book["path"];
$files = scandir($path);
$files = array_diff($files,array('..','.'));
return $files;

Additional Notes:

PHP-FPM restart fixes the issue. The OS has no issue accessing these files during an outage.

[[email protected] audiobooks]# stat /var/www/audiobooks/repository/Some\ Series/Some\ Title/01\ Some\ Title.mp3
File: '/var/www/audiobooks/repository/Some Series/Some Title/01 Some Title.mp3'
Size: 4170169         Blocks: 8152       IO Block: 16384  regular file
Device: 77h/119d        Inode: 179         Links: 1
Access: (0555/-r-xr-xr-x)  Uid: (   48/  apache)   Gid: (  996/   nginx)
Access: 2018-03-31 17:09:58.810843700 +0000
Modify: 2018-03-21 20:33:16.000000000 +0000
Change: 2018-04-01 05:58:06.448224400 +0000
Birth: -

PHP Version:

php72-php.x86_64                        7.2.4-1.el7.remi              @remi-safe
php72-php-cli.x86_64                    7.2.4-1.el7.remi              @remi-safe
php72-php-common.x86_64                 7.2.4-1.el7.remi              @remi-safe
php72-php-fpm.x86_64                    7.2.4-1.el7.remi              @remi-safe
php72-php-json.x86_64                   7.2.4-1.el7.remi              @remi-safe
php72-php-mbstring.x86_64               7.2.4-1.el7.remi              @remi-safe
php72-php-pdo.x86_64                    7.2.4-1.el7.remi              @remi-safe
php72-php-pecl-http.x86_64              3.1.1~RC1-2.el7.remi          @remi-safe
php72-php-pecl-propro.x86_64            2.0.1-4.el7.remi              @remi-safe
php72-php-pecl-raphf.x86_64             2.0.0-5.el7.remi              @remi-safe
php72-php-pecl-zip.x86_64               1.15.2-1.el7.remi             @remi-safe
php72-php-xml.x86_64                    7.2.4-1.el7.remi              @remi-safe
php72-runtime.x86_64                    1.0-1.el7.remi                @remi-safe
How to&Answers:

Try first testing whether the directory exists and is readable (better yet, wrap it in some class method).

If the test fails, and you suspect it is due to CIFS having gone AWOL, try issuing a clearstatcache(). If the OS can access the share, this means the internal SMB caches are solid, but this just might not be the case for the PHP copy, which is shared and centralized inside the FPM module.