mjhjmtu

I am trying to streamline my development and deployment process for the maintenance of my website, which is coded in PHP. The directory structure was initially set up by ISPConfig. The machine is running CentOS 6.9.

My problem is that when in a folder with path /var/www/clients/client1/web1, every operation is forbidden to me even when logged in as root user, not just while using sudo.

In that folder and only there, I cannot:

• 
  mkdir a new directory (fails with "mkdir: cannot create directory 'test': Permission denied")


• 
  mv an existing directory (fails with "mv: cannot move 'web' to 'web.old': Permission denied").

ll /var/www/clients/client1/ gives me this:

drwxr-xr-x 4 root root 4096 Jun 19 2017 .
drwxr-xr-x 3 root root 4096 May 16 2014 ..
drwxr-xr-x 11 root root 4096 Mar 11 11:38 web1
drwxr-xr-x 9 root root 4096 Apr 13 2015 web11

ll /var/www/clients/client1/web1/ gives:

drwxr-xr-x 11 root root 4096 Mar 11 11:38 .
drwxr-xr-x 4 root root 4096 Jun 19 2017 ..
drwxr-xr-x 2 web1 client1 4096 May 16 2014 cgi-bin
drwxr-xr-x 20 root root 4096 Jun 19 2017 log
drwx--x--- 2 web1 client1 4096 May 16 2014 private
drwx------ 2 web1 client1 4096 Mar 11 11:38 .ssh
drwxr-xr-x 2 root root 4096 May 17 2017 ssl
drwxr-xr-x 11 web1 client1 4096 Mar 24 19:22 subdomains
drwxrwxr-x 4 web1 client1 36864 Mar 24 20:38 tmp
drwxr-xr-x 22 web1 client1 4096 Mar 24 20:07 web
drwx--x--- 2 web1 client1 4096 May 16 2014 webdav

However, I can use chmod on existing directories.

I've checked rwx permissions on the entire path and nothing seem out of place to me.

SELinux is disabled.

There are no quotas in place and the disk usage is at 36%.

My question is: What other factors may lead to a "permission denied" message to the root user?

[EDIT]

lsattr . in /var/www/clients/client1/web1/web gives the same line for each file and directory in it:

[root:/var/www/clients/client1/web1/web]# lsattr .
-------------e- ./stats

lsattr . in /var/www/clients/client1/web1:

[root:/var/www/clients/client1/web1]# lsattr .
-------------e- ./cgi-bin
-------------e- ./ssl
-------------e- ./subdomains
-------------e- ./webdav
-------------e- ./log
-------------e- ./web
-------------e- ./private
----------I--e- ./tmp

However, lsattr . in /var/www/clients/client1 gives this:

[root:/var/www/clients/client1]# lsattr .
-------------e- ./web11
----i--------e- ./web1

mount gives me this in both /var/www/clients/client1/web1 and /var/www/clients/client1/web1/web:

[root:/var/www/clients/client1/web1]# mount
/dev/simfs on / type simfs (rw,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type devtmpfs (rw,relatime,mode=755)
none on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
/dev/simfs on /var/www/clients/client1/web1/log/atlas-demo type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/atlas-demo-api type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/kinetic type simfs (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/cloud type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/analytics type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/vcs type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/issues type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/webmail type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/downloads type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web11/log type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/preprod type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/atlas-demo type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/atlas-demo-api type simfs (rw,relatime)
/dev/simfs on /var/www/clients/client1/web1/log/kinetic type simfs (rw,relatime)

The fact that the filesystem type of all your non-virtual filesystems is simfs suggests you're inside an OpenVZ Virtuozzo container.

The lower-case i in lsattr output indicates that the file or directory is set as immutable: even root must clear this attribute first before making any changes to it. With root access, you should be able to remove this with chattr -i /var/www/clients/client1/web1, but there is probably a reason why this was done in the first place; you should find out what the reason was and whether or not it's still applicable before removing it. There may be security implications.

The upper-case I in lsattr means the directory is being indexed using hashed tree structures; it should have no applications impact, other than possibly improved performance with directory listing operations. (Maybe the /var/www/clients/client1/web1/tmp directory can occasionally contain huge numbers of temporary files, slowing down the application?)

The lower-case e indicates "extent format", which is a new scheme of tracking disk block allocations introduced in ext4 file system type. (The attribute is related to backwards-compatibility mechanism that allows ext4 filesystems to be accessible as ext3 if a system does not support ext4.) It suggests that the underlying filesystem under simfs is probably ext4.