Permission changed on my bash script

popnoart · December 12, 2025, 4:34pm

I have a bash script to backup DB. It’s on:
/home/username/web/domain/scripts/BackupDB.sh
I give it permission with chmod +x but everyday the permission reverts and I get Permission denied.
This script is run with a cronjob once a day, permissions are given by the user of that account.

What is changing the execution permision? Should I put the script on another path?

Thanks!

sahsanu · December 12, 2025, 5:09pm

By default users can’t create dirs in /home/username/web/domain/

Could you please show the output of this command?

namei -l /home/username/web/domain/scripts/BackupDB.sh

I don’t know of any scheduled maintenance task used by Hestia that could change those permissions every day.

You could use /home/username/web/domain/private/

jasonwch · December 13, 2025, 3:20am

I;ve tested on my server, seems I can also create directory inside /home/username/web/domain/ But just not /home/username/web/

popnoart · December 13, 2025, 7:53am

Hi, thanks!
I’ve moved the file to /home/user/scripts/BackupDB.sh

Cronjob this night have been ok, let’s see next night.

About namei -l, this was my previous tree:

drwxr-xr-x root               root               /
drwxr-xr-x root               root               home
drwxr-x--x username           username           username
drwxr-x--x root               username           web
drwxr-x--x username           username           domain.com
drwxrwxr-x username           username           scripts
-rwxrwxr-x username           username           BackupDB.sh

Probably not what should be

sahsanu · December 13, 2025, 12:40pm

Ok.

It’s all ok but I see one “problem”, it’s not related to the issue executing the script and it’s not your fault.

Directory domain.com has 751 permissions but by default, Hestia should use 551 so the user can’t create/delete directories inside that dir. And that’s correct when adding the web domain but when rebuilding it, it changes the perm to 751 and this should only happen if you enabled directive DOMAINDIR_WRITABLE=yes

This change added this:

github.com/hestiacp/hestiacp

Allow for optional domain directory write permissions

main ← ev0net:func/evonet-domaindir-writable

opened 08:28PM - 26 Oct 23 UTC

ev0net

+16 -3

For security reasons, my applications require writeable storage at /home/user/we…b/domain.tld/. I've been hacking hestia on install/upgrade to achieve this. I'd like to see it integrated. /home/user/web/domain.tld/ writability will only occur when the user adds optional: `DOMAINDIR_WRITABLE='yes'` to `/usr/local/hestia/conf/hestia.conf`. Additionally, the user will have to modify their open_basedir in their php templates. The way I've changed the hestia code does not impact default functionality of non-writable /home/user/web/domain.tld/ at all and does not require a new hestia.conf key=value to maintain this default functionality. Allowing a writable /home/user/web/domain.tld/ is common for panels and providers. While I understand hestia allows for a sub directory under public_html and setting that directory to docroot, this is unnecessary hassle with negligible security benefits.

But when adding support to restic, this line was modified:

github.com/hestiacp/hestiacp

func/rebuild.sh

68f5e1a0c


      
          	no_symlink_chmod 751 $HOMEDIR/$user/web/$domain \
          		$HOMEDIR/$user/web/$domain/stats \
          		$HOMEDIR/$user/web/$domain/logs

@eris do you know whether that change from no_symlink_chmod $DOMAINDIR_MODE to no_symlink_chmod 751 is because some requisite to restic backups? If no, let me know and I’ll open a PR to fix it.

popnoart · December 14, 2025, 9:19am

Thanks a lot! It’s working now in the new path without problem!