Permissions not inheriting to files and folders in linux mint

Thanks Arnold here at the results what I have done so far with the folder call DB-3-10, hourly backup are being saved in this folder by our sesame database with 644 permission which need to be changed to 777 please advise

manager@Sesame-mint ~/Desktop/Sesame2 $ umask
0002
manager@Sesame-mint ~/Desktop/Sesame2 $ getfacl DB-3-10
# file: DB-3-10
# owner: manager
# group: manager
# flags: -s-
user::rwx
user:manager:rwx
group::rwx
group:manager:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:manager:rwx
default:group::rwx
default:group:manager:rwx
default:mask::rwx
default:other::rwx

after all above the files are still being created 644

-rw-r--r--+ 1 manager manager 1669067837 Feb 10 19:27 DB-3-101518308853.dat
-rw-r--r--+ 1 manager manager  240996800 Feb 10 20:27 DB-3-101518312462.db
-rw-r--r--+ 1 manager manager 1669072653 Feb 10 20:27 DB-3-101518312462.dat
-rw-r--r--+ 1 manager manager  240996800 Feb 10 21:27 DB-3-101518316071.db
-rw-r--r--+ 1 manager manager 1669072653 Feb 10 21:27 DB-3-101518316071.dat
Thanks

777 permissions apply to directory and executeables
666 is the equivalent in files.

Usually, backups should not be readable, not sure what your backup process is.

What backs up? What are the umask setting for the user whose credentials or under whose credentials the backup runs, note umask 0002, means no world/other write rights.

We are actually copying live database copies to DB-3-10 folder for backup and execution purpose these copies need to be executed by few users whom access these files using smb shared folder from windows PC's, the sesame db application runs on Linux mint machine as user manager, user manager and other three users are also members of the group manager.
Thanks,

Has consideration been given to using replication to setup a second system/instance that can be queried
Having read access provides the user access to the data without alteration right.

Based on the ACL, members of the manager group prinary (-g) or secondary (-G) will based on the ACL will have  full rights.

Using a cron to run setfacl to recursively apply the ACL to the folder is needed to reapply your settings on new files.

The + on the end of permissions in the listing indicates ACL,additional settings.

Getfacl on a db file does it reflect the same setting as the folder settings you posted?

Hmm files acl looks different
manager@Sesame-mint ~/Desktop/Sesame2/DB-3-10 $ getfacl DB-3-101518290818.db# file: DB-3-101518290818.db
# owner: manager
# group: manager
user::rw-
user:manager:rwx                #effective:r--
group::rwx                      #effective:r--
group:manager:rwx               #effective:r--
mask::r--
other::r--

As noted, in Linux/unix the enhanced ACL does not inherit, you would need to rerun from cron a setfacl with your rights and applied recursively....

ok so should I apply setfacl -R -d -m on user, group or other, also should I apply it on folder or files inside the folder and how often should I run cron.
Thanks,

So I guess there isn't any default solution to  get this fixed except running a manual cron?

Right.
I am still puzzled why you need write rights if these are just being queried/read.

We need rwx on all files being created in in this folder because we are using these files as a backup and they're being executed by few users for data alterations and upgrade as well.

a db file can not be executed.  So not clear. commonly, the execute bit needs to be applied manually as well.

you would rerun the chmod -RH to apply the exec bit....

We open dat files not db and thank you so much for your valued time I will still dig more to find solution to make permission thing happen automatically if not then I will apply your crontab suggestion.

Couldn't get permission issue fixed so finally setup a cron to change permissions.