Sunday, June 3, 2018

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

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.

[root@audiobook 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 

1 Answers

Answers 1

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.

If You Enjoyed This, Take 5 Seconds To Share It

0 comments:

Post a Comment