Permission issue after updating to

Discussion in 'General' started by Seidr, Feb 28, 2013.

  1. Seidr

    Seidr New Member

    [Possible bug] Permission / mount issue after updating to

    Please read posts 2 & 3 also - they contain further information regarding this issue.

    After updating to ISPConfig, 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'.

    Appreciate any pointers you could give! :)
    Last edited: Feb 28, 2013
  2. Seidr

    Seidr New Member

    Note: after a reboot, I was able to remove the web4 directory, however that seems a bit of an excessive requirement just to remove a directory!
  3. Seidr

    Seidr New Member

    After a little more investigation, it appears there is a mount point that is added when a site is added to ISPConfig, which links the log files to the log directory. I.E.

    [email protected]:/var/www/clients/client0# mount | grep web4
    /var/log/ispconfig/httpd/test.local on /var/www/clients/client0/web4/log type none (rw,bind)
    After unmounting this point, I was able to remove the directory.

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

    till Super Moderator Staff Member ISPConfig Developer

    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.

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

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

    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.

    There is no bug in the things you described above.
  5. Seidr

    Seidr New Member

    Hi till,

    Thanks so much for getting back to me. I must of missed that in the ChangeLog - sorry about that.

    I'll give it another try and make sure nothing is using the directory at the time. If the issue persists I'll update this thread.

    Cheers :)
  6. jeppunen

    jeppunen New Member

    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 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?
  7. btom

    btom New Member

    I have that problem too on centos 6.4.
    Cannot delete /var/www/clients/client6/web11/log.

    /dev/mapper/vg_isp-lv_root on / type ext4 (rw,usrjquota=aquota.user,,jqfmt=vfsv0)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    devpts on /dev/pts type devpts (rw,gid=5,mode=620)
    tmpfs on /dev/shm type tmpfs (rw)
    /dev/sda1 on /boot type ext4 (rw)
    /var/log/ispconfig/httpd/ on /var/www/clients/client6/web11/log type none (rw,bind,nobootwait)
    none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
    sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
    /var/log/ispconfig/httpd/ on /var/www/clients/client0/web12/log type none (rw,bind)
  8. btom

    btom New Member

    I had the same ptoblem on my clean install on centos 6.4.
    Upgrade ISP config to ISPConfig- has fixed it.
  9. baskin

    baskin Member

    How can we disable this?

    I have some files and folders that are outside the web folder (under /var/www/my.domain.tld) and after upgrading to and, i cannot delete them...
  10. orasis

    orasis Member

    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.
  11. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
  12. orasis

    orasis Member

    yes till, thanks for the answer, I know you have set the immutable bit, and I learned how to use it, very simple indeed.

    I had to unset it using
    chattr -i web1
    delete the directories I wanted and set it back like:
    chattr +i web1
    fine and easy, but until I found out about it I lost 1 hour of web design :D
    hope all is well dude have a great day !

    put an option in next versions of ispconfig to temporarily enable disable this. you can even make it revert back to +i if forgotten unlocked for a certain period of time.

  13. undoIT

    undoIT New Member

    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!

Share This Page