Database file not opening over the network

What are the permissions for a user that can't open the database?
You might try changing the permissions to 0664 to include the group or even 0666 if the Linux box is not recognizing the AD groups.

Thanks Davis, Linux mint box is not part of AD i have tried changing permissions for users and group=766 on the folder DB-3 but it only changes it for existing files, every time new file is created it goes back to 644 which leaves users unable to execute the .db files on their machines and i have to run chmod 766 few times a day so look like folders permissions are not inheriting to newly created files.

Here's how to do it for all new files in a given folder using Mint:
https://forums.linuxmint.com/viewtopic.php?t=254289

Daves that post does not answer my question in any mean my problem is I want to set same permission for new files created in DB-3 folder chmod -R 755 does the job but for existing files only it does not effect new files.
Thanks

Did you scroll down to the askers entry:
"The solution which solved my problems:"

Davis, I tried it, it only changes permission for existing files new file are still showing up with 644

What is the version of Mint?

manager@Sesame-mint ~ $ uname -a
Linux Sesame-mint 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

I have even setup setgid on DB-3 folder still new files are showing with 644

chmod g+s <directory>  //set gid
setfacl -d -m g::rwx /DB-3-10
setfacl -d -m o::rx /DB-3-10

Results:
manager@Sesame-mint ~ $ getfacl ~/Desktop/Sesame2/DB-3-10
getfacl: Removing leading '/' from absolute path names
# file: home/manager/Desktop/Sesame2/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:group::rwx
default:other::r-x

I think your problem is in "default:other::r-x" (the bottom line of your posting) which would mean to me that "other" users could not open the new file and write to it.
Try reading this thread:
https://unix.stackexchange.com/questions/401689/unable-to-write-on-directory-that-allowed-by-setfacl

Hmm Okay how can I change this though

Read the thread I posted.

But why do you think those default others is preventing permission inheritance for new files for users and manager even though according to above results default others have r-x but my new files are still being saved with 644  
Thanks

To get to why, we need to know what is the filesystem type? (EXT2, EXT3, ReiserFS, etc.)

It's ext4

manager@Sesame-mint ~ $ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  7.8G  4.0K  7.8G   1% /dev
tmpfs          tmpfs     1.6G  7.9M  1.6G   1% /run
/dev/sdb1      ext4      1.8T  1.5T  242G  86% /
none           tmpfs     4.0K     0  4.0K   0% /sys/fs/cgroup
none           tmpfs     5.0M     0  5.0M   0% /run/lock
none           tmpfs     7.8G  860K  7.8G   1% /run/shm
none           tmpfs     100M   16K  100M   1% /run/user

Ext4 only allows a total of 32 ACL's and 32 default ACL's that it will enforce so, if this winds up being number 33 it won't get applied.
I also don't like that the folder is in the /manager/Desktop as that may wind up inheriting ACL's from the parent.
I don't do a lot with Linux; but, isn't there a public folder that would be a better place for it?

Okay, I am not sure if i can move files to another folder i will have to talk to database guys. thanks

Daves, i have tried your above suggestion from article still no luck thanks.

Thanks Davis I think I will try adding umask 0002 to /etc/profile and see what it does I will let you know the out put.

Setfacl  is being applied in getfacl results shows ugo=777 and default ugo=777 but still new backup files being created as 644 which means acl permissions aren't  being applied on new files in a folder DB-3-10 any other suggestions please

After reading many forum and applied many suggestions  did not help changing permission into new files created so I have finally tried to run chmod with cronjob which resolved the permission issues for new files in the DB-3-10 folder for now.