After updating to ISPConfig 3.0.5.1, whenever I create a new website, it's root directory (i.e. /var/www/clients/client0/web4) is set to be owned by 'root:root', instead of 'web4:client0' as expected.

In turn, when removing a site, the directory cannot be fully removed as during the removal process, the ISPConfig server script returns "rm: cannot remove 'web4/log': Device or resource busy".

On top of this, I can't seem to be able to delete this directory while logged in as the 'root' user. Neither can I create files or folders within the root site directory when the site exists (/var/www/clients/client0/web4) while logged in as the 'root' user.

Any suggestions please? ISPConfig was working perfectly for me prior to this update. While this issue does not stop me from creating new sites, I find it rather odd that sites have changed from being owned by their respective user/group to being owned by 'root:root'.

After updating to ISPConfig 3.0.5.1, whenever I create a new website, it's root directory (i.e. /var/www/clients/client0/web4) is set to be owned by 'root:root', instead of 'web4:client0' as expected.

Click to expand...

There is no issue, just what you expect is wrong. The correct permissions of the root directory are root:root in ISPConfig 3.0.5.

In turn, when removing a site, the directory cannot be fully removed as during the removal process, the ISPConfig server script returns "rm: cannot remove 'web4/log': Device or resource busy".

Click to expand...

Works fine here. Maybe you were accessing the directory at that moment with a shell user so it could not be unmounted.

On top of this, I can't seem to be able to delete this directory while logged in as the 'root' user. Neither can I create files or folders within the root site directory when the site exists (/var/www/clients/client0/web4) while logged in as the 'root' user.

Click to expand...

Thats correct as well. The directories are protected with the immutable bit.

Any suggestions please? ISPConfig was working perfectly for me prior to this update. While this issue does not stop me from creating new sites, I find it rather odd that sites have changed from being owned by their respective user/group to being owned by 'root:root'.

Click to expand...

This change was required for security issues, all directories that shall be used to store data are accessible and owned by the web user and is described in the changelog. Web users can store data in the web subdirectory which shall be accessible by http, they can store data in the webdav directory which shall be accessible by webdav and data that shall neither be accessible by webdav nor by http goes into the private directory of the site.

Could this be worthy of a bug report, or is it simply a result of upgrading to 3.0.5.1, instead of using a clean install?

I have the exact same problem with my installation. Same version of ISPConfig with me too. My install should be as clean as it can be (installed only two days ago to a blank Ubuntu 12.04 server). When I remove the site and check the /etc/fstab file, the mountpoint to the logfile has been removed, but if I type "mount" I still see the mount connection existing and this prevents the directory removal.

So it seems that the apache2_plugin.inc.php script is not able to execute the exec('umount...') command for the mountpoint removal. But the script is able to remove the line from the fstab though..

Anyone else having the same problem? Any resolution for this? Could it be that the userid the php-script is being executed (is it the www-data or the ispconfig user?) does not have proper access to umount -command?

I have directories outside webroot too and today I noticed I can change their permissions only but not delete them. And I cannot change the permissions of their parent directory even as root although it belongs to me.

I have directories outside webroot too and today I noticed I can change their permissions only but not delete them. And I cannot change the permissions of their parent directory even as root although it belongs to me.

Click to expand...

Thats correct and the intended bahaviour. The folders are protected now with the immutable bit. You can create custom folders only inside the web folder and inside the enw private folder but not in the site root anymore.

Ahhhh, relief! I lost at least an hour on this as well, mussing around with symlinks, fstab and chattr etc. I was on the right track with the immutable flag, just didn't think of checking it on web1 folder. Thanks for posting the solution that finally allowed for folder deletion orasis!