Possible to set default file permissions after saving files through Admin Panel?

I've punted this for years, but now just want to get it solved.

When editing and saving and existing file through the Admin Panel (like an .md file), the file permission changes from my server default of 664 to 644. I've got around it for years by running a quick bash script to re-adjust all the perms.

This problem becomes increasingly frustrating when trying to work with an IDE and the Admin Panel at the same time.

Its a local development server running Apache, with ownership as www-data:group-name, with my user and www-data assigned to group-name. Files are 664, folders 775.

I see you can set image cache perms in system.yaml. Is there any way to set default file perms?

Thanks.

good point 😄 - I've been doing the same (bash perm fix script) since the beginning of my grav experience...
I already thought of creating a simple file system watcher script (in python) which would do the same automatically, but was too lazy so far.
best solution, of course, would be a grav system setting as you asked far, but I doubt there is one.

I like the python watcher script idea as a stopgap, @hoernerfranz .

I'm going to keep digging on this for a few more days, and will report back if I find an elegant solution. If you end up throwing something together, would you be willing to share? I'll do the same if I end up "borrowing" your idea or finding something else.

I smell an opportunity for a plugin, but ain't nobody got time for that.

@ejstauffer , yes, of course I'm willing to share if I come up with something useful here, but I doubt that will be in the near future, so I guess you will be faster 😄.
and, yes, a plugin would be a more elegant solution, but a first look at the grav API did not bring up an event hook like 'onPageSaved' or thelike, which would make this easy.
another possibility would be to find out where in the grav admin the permission change upon save is done, then eventually create a patch/pull request.

...just for the record: here is a python3 watchdog example which could be used as a starting point, IMHO.

@hoernerfranz I started looking into it, and then the coffee kicked in. I just finished iteration one and threw it up on github. I haven't gone through and refactored it yet, but wanted to get a workable solution out the door.

https://github.com/trezcan/grav-directory-permissions-monitor

I started with watchdog (like your example link) but I wasn't happy with the resources it was using when idle (I think I figured out why later, but was already getting close with this version).

Now its time for a beer. I'll make it look more presentable next week (maybe) 😂

Cheers

Looks like its more than just changes made through the Admin UI. I left this script running for a few hours to test resources, and these were in the log file when I got back. Looks like the notifications widget and cache.

This is local. No traffic coming in.

2023-09-22 11:38:23,997 - Change detected in /var/www/ericjstauffer-dev/user/data/notifications/29988429c481f219b8c5ba8c071440e1.yaml. Ownership changed from 33 to 33, permissions changed from 33204 to 33188

2023-09-22 12:59:27,114 - Change detected in /var/www/ericjstauffer-dev/cache/doctrine/07b78d7e/e9/666c65782d6f626a656374732d757365722d67726f757073672d30376237386437655b5f5f6b6579735d5b315d.doctrinecache.data. Ownership changed from 1000 to 33, permissions changed from 33204 to 33204

oh, well, as expected, you were faster than me 😄 - I'll have a closer look at your project later, just a short note from my first glance: IMHO the script(s) could be restricted to work on the user folder, not the whole grav install directory, yes ?
plus: it doesn't matter much if permission adjustment is also done upon notifications or thelike from time to time (your next post).

FYI, I decided to incorporate the permissions monitor into this fork so it starts and runs automatically with the docker image, this is quite convenient for local development.
no need to fiddle with separate script starting, sudo etc.

Excellent addition with docker!

You are right. It only needs to monitor /user.

Also,exclude_dirs isn't functioning as intended. That being said, by only monitoring /user, the need for it becomes less important.