Solaris

Your original request: Your updated statement:
What is it you want?

Sorry , that was typo i mean its not allowing to modify / edit from user1

The umask might be coming into play. What's your umask? Change it to 000 and try again.

I don't think the umask should help.
User1 is granted read and write access only for the directory itself which means he can create, rename and delete files there, even those that do not belong to him.
Files in that directory keep their permissions so it is expected for user1 not to be able to directly modify root owned files content.

The ACL mask in a directory represents the "maximum" permissions a file can have -- it does not force new files to have those permissions. It's not like umask.

I don't understand it that way.
The ACL mask parameter when set to a directory apply to permissions set to that directory, not to existing or new files inside it.

There are two differing acl schemes floating around. We are discussing the older scheme that is in use on Solaris ufs file systems. Setting an acl on a directory does not propagate to any pre-existing files under that directory. If a file is created in a directory with an acl set, that acl is not automatically applied to the file. You can't set a file's umask with a setfacl or by any other technique. Files do not have umasks, processes have umasks.

This form of acl does have a "mask" concept. It is intended to enable a non-acl aware program to be able to interact with a file that has acls. The file owner is immune from the mask and so is the "world" (or "other"). These two classes of users are clearly defined in an identical fashion whether or not you use acls. But an acl can specify various other groups and users and these folks don't make sense to a non-acl aware program. So the idea is to use this "mask" concept. For example, if a program uses the chmod() system call to remove group execute permission, execute permission is removed from the mask. This is a controversial idea, but it does make some sense... older programs can continue to run.

If you still don't understand the mask concept, just do this:
Whenever you change the permission on a non-owner user or a group with a setfacl command, specify the -r option to recompute the mask and other than that leave the mask alone.