“Permission denied” issue when accessing ISPConfig-managed web directories

Hey folks

I ran into a common problem when using ISPConfig and wanted to share a fully compatible solution that respects ISPConfig’s permission structure while still giving sysadmins (like those in the sudo group) access to all web directories.

❓ The Problem
By default, users like rfnx (who are in the sudo group) cannot access ISPConfig-managed directories like /var/www/clients/clientX/webY/web, even for legitimate sysadmin purposes — because these paths are strictly permissioned as webY:clientX.

Changing ownership or default groups is a bad idea:

• Breaks FTP/web permissions
  
  
• Confuses ISPConfig’s permission logic
  
  
• May cause backup/quota/accounting issues

✅ The Solution (Without Breaking ISPConfig)
We’ll use POSIX ACLs to grant access to all sudo users (or any group of trusted users) without modifying ownership or groups.

ACL Auto-Fix Script
Here’s a script that:

• Grants all users in the sudo group access to all /web folders
  
  
• Ensures they can traverse parent folders (+x)
  
  
• Keeps things ISPConfig-compatible
  
  
  
  Code:

  #!/bin/bash
  # /usr/local/bin/acl_fix.sh
  # Grants access to all 'sudo' users for ISPConfig-managed web directories
  
  SUDO_USERS=$(getent group sudo | cut -d: -f4 | tr ',' ' ')
  
  for user in $SUDO_USERS; do
    echo "Applying ACLs for $user..."
  
    for dir in /var/www/clients/client*/web*/web; do
      [ -d "$dir" ] || continue
      setfacl -R -m u:$user:rwX "$dir"
      setfacl -R -d -m u:$user:rwX "$dir"
    done
  
    # Traversal rights
    setfacl -m u:$user:--x /var/www/clients
    for client in /var/www/clients/client*; do
      [ -d "$client" ] && setfacl -m u:$user:--x "$client"
      for webdir in "$client"/web*; do
        [ -d "$webdir" ] && setfacl -m u:$user:--x "$webdir"
      done
    done
  done
  

  ✅ Save this as /usr/local/bin/acl_fix.sh
  ✅ Make it executable: chmod +x /usr/local/bin/acl_fix.sh
  
  Automation via Cron
  Add to root's crontab to run every 5 minutes:
  
  
  
  Code:

  sudo crontab -e

  Add:
  
  Code:

  */5 * * * * /usr/local/bin/acl_fix.sh

  Feature Suggestion for ISPConfig
  It would be fantastic if ISPConfig included a feature like:
  
  ☑ Automatically grant ACL access for sudo users (or selected system users) on new web directories.
  
  Or even a server hook that allows sysadmins to define post-creation ACL behavior for /web folders.
  
  Why This Matters
  • ✅ Keeps ownership/group untouched → ISPConfig stays happy
    
    
  • ✅ Allows system admins to manage and debug sites easily
    
    
  • ✅ Does not interfere with backups, FTP, permissions
    
    
  • ✅ Future-proof and works even for new websites
    
    
  • ✅ Scalable for teams (just add users to the sudo group)
  
  
  Hope this helps others!
  
  Let me know if you have improvements or feedback — and big thanks to the ISPConfig team for such a robust and open system
  
  Cheers!
  rfnx

 

Hi Till,

Thanks for your detailed explanation and the insights regarding permission handling in ISPConfig.

Of course, I understand that for admins with sudo rights, accessing web directories via sudo -s or sudo -s -u webX works well and is a standard approach.

I think that makes sense as I often had that issue occurring and spent hours to find out what's up ...

The issue, however, is that many ISPConfig users are not experienced system administrators. For less technical users (or beginners), such commands are often not practical or they may lack the required permissions, which frequently leads to access problems and errors.

Therefore, I'm about to find a solution that respects ISPConfig’s permission structure while also making access easier for all users—without requiring them to spend hours reading documentation or working as root or web user.

The problem is more complex than initially thought. But we are continuing to work on it and are optimistic that by tomorrow we will have a ready, practical script that reliably solves this issue.

But I appreciate the opportunity to collaborate and think this through together.

Today I made good progress understanding the permission challenges with ISPConfig and testing different approaches. While it’s more complex than expected, I'm close to a working solution. Will share an update and the script very soon
Without AI, that would be too much for me!

Let's take an example:

Today I created newly installed 2 webs and the appropriate FTP, filled in a web and the browser linked the URL to the second web. Of course he shouldn't, but that's why I got down to it with him to get the problem under control finally. I hope this doesn't bother you!??!

I was always root user on my installation because I'm working on a VPS. nevertheless, I had the problem again and again...

— stay tuned!
Hopefully I'll get my solution working later tomorrow

 

and that's exactly why they should be limited in their access they way ispconfig does it.

unless a user knows what they are doing they should not be able to easily access any other users website area, and especially shouldn't be able to sudo to root.

they did this and you want to allow them to be able to access another users website area? just imagine the damage they can cause to that other website, and as root they could easily break the entire server.

a user already can already get full access to any website they own via a jailkitted ssh login. if they have multiple websites, then they'll need to login multiple times as different users, but they still have full access, and they're protected from accidentally doing something in another website area as the wrong user, they don't need any more rights.

a knowledgeable server admin can also, already, access every users website area. if they don't know what they're doing well enough then they shouldn't even have their own login to the server unless it's their own server, only running their own websites.

 

Not really! That can easily be solved by giving the "DAU" only access to a GUI that handles every sudo action them are allowed to do. They won't get sudo access as long the ISPC Admin doesn't give them the access, ISPC Admin alone has the access data and has to enter it to get access to what only he may know. The DAUs won't get access without having the access data

The tool I'm creating is for the ISPC Admin to have a better overview and perform actions more easy and without having to use the terminal. But whenever the Admin decides to give a User access to perform actions, he can create a user that is only allowed to perform the needed actions

It's NOT about to give the fox the key to the chicken coop !!!
It's more to give the chicken farmer a tool with which he can simplify his work and feed his chickens

 

OK got that and am also finding out more and more about how ISPC Is performing while I'm about to create the CheckServer tool.
Thanks for the Info ...