Indeed, the Filesystem class silently ignored errors in 2.2, whereas we throw exceptions now in 2.3. I don't know what to do here. Can we safely ignore such problems when writing files in the cache?

On my local machine, I have the same problem (my Symfony codebase is on an NTFS drive, for Windows compatibility, mounted in Ubuntu with 777 perms for al files).

I fixed this locally, by just commenting out the line of code that raises an exception on chmod errors:

File: src/Symfony/Component/Filesystem/Filesystem.php
Line: 177

Change:
throw new IOException(sprintf('Failed to chmod file %s', $file));

To:
//throw new IOException(sprintf('Failed to chmod file %s', $file));

This works for me (since all my files are 777, I don't care about a chmod exception, there's no way logically that it could affect me). However, this is not a nice solution. Perhaps if there was some way of checking if the volume in question supports chmod'ing, and if it doesn't then don't bother to raise an exception... that would help? But I have no idea if such a check is possible.

This bug is due to 3158c41, which took the wrong approach.

That was my commit :-(

https://github.com/symfony/symfony/blob/2.2/src/Symfony/Component/Config/ConfigCache.php#L106 -> previously, the chmod() was considered optional to success and errors were silenced.

Fix it like so?

https://github.com/webfactory/symfony/compare/symfony:2.3...issue-8205

That looks wrong to me as you might want to have the exception. In the case of cache generation, we don't care, but it might be of importance somewhere else. The safest is probably just to revert the changes made and keep the Filesystem::dumpFile for BC reasons.

Thought about it, but what I had in mind was breaking BC :(

One possibility left would be an exception subclass for a failing chmod so we could catch and ignore that when dumping a ConfigCache.

@mpdude Having a subclass exception looks overkill to me. This code should be as simple as possible. So, reverting the culprit is probably the best option.

I'm also getting this issue when in OSX on a truecrypt mounted drive. It works when I use the regular hard disk mount. They both use the same filesystem (HFS), so I think it's because one of them is mounted by my user instead of the system.

Additionally, if I comment the line that throws an exception I get:
file_get_contents(/Volumes/Gyges/symfony/app/cache/dev/classes.php.meta): failed to open stream: Permission denied in /Volumes/Gyges/symfony/vendor/symfony/symfony/src/Symfony/Component/ClassLoader/ClassCollectionLoader.php line 71

I just met the same problem. My project is accessed via a samba share and I wanted to add the Symfony command line tool in PhpStorm, but adding it returned me : IOException: Failed to chmod file /Symfony/app/cache/dev/appDevDebugProjectContainer.xml.

I solved (temporarily?) the problem by re-fixing the ACLs default permissions of my specific unix group for development on the entire project (rwx).

I'm currently setup on Windows which is where all of my source files are located. My guest machine is Linux (Ubuntu 12.04) using Samba to mount web directories from the host. My original mount directive specified my user account as the owner and www-data as the group. Switching the owner to www-data fixed this error for me...

File: /etc/fstab

//host/www /media/www cifs credentials=/home/myuser/.smbcreds,uid=www-data,gid=www-data,file_mode=0664,dir_mode=0775 0 0

Will this be fixed in 2.4?

Problem still exists in version 2.4. Any new ideas how to fix it?

@fabpot should we revert 3158c41?

Is there a workaround for this? I'm on OSX developing on a mounted partition.

@mpdude or maybe you have another idea on how to fix it?

Perhaps you could add support for $mode = null which would deactivate the chmod. This way, cache generation would not set permissions. One needing to protect its cache directory could manually chmod the folder itself.

Problem still occurs, I'm hitting it right now.

Can we consider reverting the commit that broke backward compatibility?

In latest symfony 2.4.2 problem still appears. What is quite strange I have two working environment (home & office) configured in the same way, and I am experiencing this only in home. The best way to reproduce this is to make 2-3 request simulatenously and some of those request will fail.

My configuration is similar to @Acorath : guest machine is Ubuntu, which uses sources mounted via cifs (and windows file sharing on the second side)

//PIOTR-HOME/vhosts/centos6 /var/www/vhosts cifs user=vbox,pass=,uid=apache,gid=apache,file_mode=0777,dir_mode=0777 0 0

PS. setting 0777 chmod does not help

I have found tricky solution for this (what also gives visible performance improvement):

//PIOTR-HOME/vhosts/centos6 /var/www/vhosts cifs user=vbox,pass=<password>,uid=apache,gid=apache,file_mode=0777,dir_mode=0777 0 0
tmpfs                   /var/www/vhosts/symfony2-project/app/cache tmpfs rw,size=64m 0 0

This additional line mounts the cache folder as native unix ramfs. It solves the problem in some kind of "hacky" way (but works).

NOTICE! If you have profiler enabled, it can consume really significant amount of space for its caches so I suggest to modify the size of ramfs according to your needs.