This post is just to help clarify how *nix based OSes do file system permissions.
On such systems, there is a global list of users, and groups. Users can be members of multiple groups, and groups can contain multiple users as members. A user can get access credentials through either their user-ID, or their group-ID.
For any given file or directory, there are 3 access lists. One for its owner. One for a group-ID that its owner belongs to, and one for “Everyone else”.
Each of these lists has 3 permissions that can be selectively enforced. Read, Write, Execute. These are given the designations of (r)ead, (w)rite, and e(x)ecute.
When you do an ls -ll inside a folder, you will get output that looks like this:
lrwxrwxrwx 1 root root 17 Apr 25 05:55 P2P -> /mnt/HD/HD_a2/P2P
lrwxrwxrwx 1 root root 20 Apr 25 05:55 Public -> /mnt/HD/HD_a2/Public
lrwxrwxrwx 1 root root 13 Apr 25 09:08 Volume_1 -> /mnt/HD/HD_a2
drwxr-xr-x 2 root root 1024 Apr 25 09:09 test
lrwxrwxrwx 1 root root 15 Apr 25 09:08 v221w -> /mnt/USB/USB1_b
What does any of this even MEAN, you may ask yourself.
Well. The column on the left contains the filesystem flags. the furthest to the left, is a designator. In this case, several of these are symbolic links. These point elsewhere in the file system, and get the designation flag ‘l’ in the first position of the flags field. The next 3 are for the OWNER of the file. Again, (r)ead, (w)rite, and e(x)ecute. The next three after that, are for the GROUP the owner belongs to. Again, (r)ead, (w)rite, and e(x)ecute. The last column is for “Everyone else.”
You can see from my sample, that some of the flags have a ‘-’ in there, instead of one of the mentioned flags. This means that the permission is not set or enabled.
After that, we have the [OWNER] and the {GROUP] identifiers. These objects were created by the root user, who is a member of the root users’s group (root). Other users can make use of them, because of the permissions defined for [OTHERS] seen in the flags table we just discussed.
for the symbolic links in that listing, the final entry shows where the link points to, or for normal files and directories, what the name of the file or directory is.
“So what are those numbers – you know, that ’ 777 ’ nonsense in chmod?” you might ask. I will gladly explain.
Since there are 3 bits that can be set, for each type of access (Owner, Group, and Others), there are a maximum of 8 possible combinations of permissions (set and unset) for each of those. (2^3=8) Since one of the options allowed is “No permissions enabled”, we start counting at 0. That means we have possible permission sets in the range of 0 to 7. Here is what each set translates to.
0 No permission —
1 Execute permission --x
2 Write permission -w-
3 Execute and write permission: 1 (execute) + 2 (write) = 3 -wx
4 Read permission r–
5 Read and execute permission: 4 (read) + 1 (execute) = 5 r-x
6 Read and write permission: 4 (read) + 2 (write) = 6 rw-
7 All permissions: 4 (read) + 2 (write) + 1 (execute) = 7 rwx
So, when you put a line like this:
chmod 777 [somefile]
you are telling the system that the creator/owner has Read, Write, and Execute-- the group he belongs to also gets Read Write and Execute, and EVERYONE ELSE ALSO gets Read, Write, and Execute.
How does this translate to the windows side of things though, you may well ask next.
SAMBA, the windows compatible file share service running on the MyCloud, creates a user mapping between users and groups created on the MyCloud, and the file security flags it tells windows clients each user or group member has to the share, based on the file system ownership and flags set on the *nix side, in addition to any special restrictions imposed by its share configuration definition. (not really visible by end users, but still accessible to people who know how to edit it-- we will leave it at that. If you dont know what you are doing, dont bother. Best advice.) This is why you saw “WWW-Data” and the like in the security tab for that file. The Samba service creates several known users and groups for its own accounting, so that it can do this mapping between windows style permissions, and *nix style permissions. When a public user creates a file on the MyCloud using a windows file share, Samba creates that file using the [nobody] user, who is a member of the group [share]. Samba is configured to give such created files ‘777’ access by default. It is obvious that the WD transfer utility you used to copy those files to the MyCloud, saved them under a different owner and group membership, and did not give them the proper file system permissions. This is why you cannot execute the .exe file. (you are not granted the execute permission)
By changing the ownership and group assignments of these files, then setting the proper file access, Samba will report appropriate permissions to the windows host, and the windows user will be able to use them as intended.
I hope that was helpful in understanding this problem, and how the proposed solution should fix it.
