OK, I'm beginning to understand you. But I'm not sure I'm understanding you correctly.
I have no idea where that output you showed there comes from. But it is pretty unambiguous what it means. You are looking at a file system object, such as a file or directory (there are a few others, but they are uncommon). Whatever tool put up that output is telling you the following:
- This object is owned by a user whose name is "user-x". The permission bits for user access are allowing that they can read and write, but not execute.
- This object is owned by a group whose name is "user". The permission bits for group access are allowing read, but not write or execute.
- The permission bits for anyone else allow read, but not write or execute.
To understand this, you need to first know a few fundamentals. In Unix (which FreeBSD is one variant of), every file system object has a user who owns it, and a group who owns it. In typical textbook examples the users have names such as alice, bob, charlotte, david, eve, ... and the groups have names such as marketing, engineering, sales, ... One of the things that makes your example a little confusing is that the username here is "user-x", and the group name is "user".
The next thing to know is: any entity that uses the computer is known as a "process". And each process also has a user and one primary group (they also can have additional groups). To find out what your user and group(s) are, you can run the "id" command from a shell.
The permission system in Unix (access control to file system objects) works roughly as follows:
- If the user of the current process is the same as the user who owns the object, then the three permission bits for "user access" apply. The three bits are <R>ead, <W>rite and e<X>ecute. So the first line in the list above is that the permission bits for user access must be "rw-" (the normal way to print them is to print the bits if allowed, and a dash if not allowed).
- If the user doesn't match, then the system checks if the group of the current process matches the group that owns the file. Again, there are the same three permission bits, which in this case seem to be set to "r--".
- Lastly, if neither user or group(s) matched, then we have three permission bits for "other", also known as "anyone else", which in our example also seem to be "r--".
- In summary, the permission bits here are "rw-r--r--", which is the most common permission for files.
Now, what you want is the group "user" to also have write permission. From a command line, that's completely trivial: Just run the command "chmod g+w ..." on the object (replace ... with the name or full path of the object). I have no idea how to do this in your GUI tool. I would suggest that you read about the chmod command, and how permissions are encoded in there; in short: the "g+w" notation means set the w permission in the group triplet.
The other thing you want makes no sense in the normal Unix permission system. You want to also allow group "wheel" to write. There is simply no provision for a file system object to have TWO owning groups, and therefore two sets of permissions. You'll have to find a different way to get there. You can try doing things with all processes in certain groups having multiple groups, but that might have unintended side effects. You might instead allow *all* other processes to write (by setting "chmod o+w ..."), but that could be very dangerous, since now all other users (not just wheel) can write. You could simply ignore the problem, since most processes that are in the group wheel are also the root user, and root can do whatever it wants, the permissions don't even apply to it. You could instead learn about ACLs (access control list, a complicated way to express access permissions that extends the 3x3=9 permission bits), but ACLs are not implemented consistently on all systems and file systems, their inheritance properties are tricky, and they are hard to learn.
I think what we really have here is an XY problem, combined with a language barrier. You are asking us how to set permission bits, but you are not explaining what you are really trying to accomplish. Please explain the underlying problem. And please start using the common Unix language (referring to things as directories, permissions, ...); the term "folder" is a Microsoft-ism, and the way you explain granting permissions shows that you are thinking about these things backwards.