I have run into an interesting puzzle.

How do I correctly configure permissions and ownership for a directory of shared data files in a mixed Slackware and Windows network?

For many years I used a partition scheme in Windows to separate system files from application files and data files. My operating system was always stored in C:, my applications in D:, and all user data files in E:. I established that habit going way back into the DOS days. Partitions were nothing new to me when I started tinkering with GNU/Linux.

With my new box I moved all of my data files from my Windows box E: partition to /home/Files.

I want all files in this directory to be fully accessible by anybody in the users group. Minimally that requires recursively using the GID bit to ensure all group ownership is assigned to users. Straightforward. Works fine here. No problems.

The challenge is ensuring all files are always writable by anybody in the users group. That requires 66x permissions.

The default Slackware umask is 022. That means all directories will be created with 755 permissions and all files with 644 permissions. Changing the default umask to 002 would solve my problem with respect to all directories and files I want writable by groups as well as individuals. All directories would receive permissions of 775 and all files would receive permissions of 664. Exactly what I want for /home/Files.

However, every other directory and file on my system would receive the same assignments. Do I want to do that? I'm hesitant to tinker with umask. I'm nowhere near being a 'nix expert to speculate on all the ramifications of changing umask like that. Should I set umask to 002 in /etc/bashrc, which would override the default value of 022 set in /etc/profile? Then in the root's ~/.bashrc, set umask back to 022 so anything created by root --- usually administrative files, are set to 644? Would that approach succeed?

Next I look into ACLs. I run the following command:

setfacl --default --modify group:users:rw- -R /home/Files

This succeeds with respect to the desired 775/664 permissions. Wonderful! Problem solved? Nope, two new hurdles appear.

First problem. Files copied to /home/Files retain original permissions. If I copy a file from my home directory to /home/Files, the file permissions remain 644, as originally set by the default umask. Thereafter nobody in the users group can modify that particular file despite all files being owned by the users group as directed by the GID bit. The cp --no-preserve option does not bypass the problem.

Second problem. I am running Windows NT4 in VirtualBox. I also still have my separate Windows NT4 box that I network on occasion. Through networking and Samba I share /home/Files. My Windows systems mount that directory as an E: drive, just like with my original standalone configuration. The only difference is that E: is now a network mapping rather than a local partition. That was a nice little trick to help me avoid rewriting Windows scripts, shortcut paths, etc.

With ACL enabled as above, and umask at the default 022, from within Windows I created a directory and the permissions were correct: 2775. No problems creating directories. Good!

When I save or create files from within Windows to /home/Files (E: drive), the files are not assigned the correct permissions. Both the user and group have read-write permissions, which is good --- I'm half way there, but Windows stamps every damn thing as executable too, which I don't need or want in this directory. Everything is this directory is a data file. There are no executables. I don't want file permissions of 774 but 664. How do I eliminate the executable bit?

Samba has some masking options. In my smb.conf, I added create mask=0664. Within Windows I copied a file to /home/Files (E: drive). The resulting permissions were 674 not 664. Weird. I created a new file and the permissions were the same 674. Not what I want. I want 664.

I tried the force create mask directive with the same result.

Regardless of how I fiddle with the samba masking, with ACL enabled as above, the group permissions always remain at rwx. For example, I set the samba create mask to 400 and the resulting file permissions will be 470.

Can I set the ACL to not create the executable bit for the group permissions? I thought I had already done that with setfacl and the rw- directive.

Hopefully I'm missing the big picture somewhere and the cure is straightforward.

I hope I haven't opened a hornet's nest here....

So far as I understand it, Windows treats everything as executable, and depends on the file extension to decide what it does. .doc opens word, etc. So the problem you have cannot really be solved by Samba, as I understand it. The important thing to remember is that even though the executable bit is set on, linux still won't execute the commands, if they are not in shell form? So for example, a pdf file listed as executable will not 'run', if you follow me. Of course, from a security perspective, it's a can of worms, but that all depends on what you are using this for. Remember, if people don't have shell access, e.g., telnet or ssh, and no physical access to your samba box, you should have no issues! Messy I know, a bit of a kludge. But then all things in mixed networks are.

Once you apply ACL's the group file permissions as reported by ls -l aren't what they seem.

Take a look at this:

In the example above I create a directory called Files with root:root 700 +SGID permissions and add a 'rwx' acl for group:fred and the same acl rule as a default to be propagated to any new files/directories created.

The ls -l clearly shows the directory as 770(+ SGID), but if you look at the output of getfacl, the group permissions are really still '---'

The +SGID is just to keep the group name the same on all files/directories created under this 'Files' directory. It's not really significant at this stage as we won't actually be using that group for granting access at all.

From playing with this a little, it appears that what ls -l is actually showing is the 'mask' value, not the underlying group permissions.


Lets create some files/directories from my normal user: fred, group:fred

As you can see, the SGID has successfully propagated the group 'root' to the new files and despite what the ls -l says, the underlying group permissions are still --- and not rws. This can be confirmed again in the getfacl (highlight red).

If you look at the blue highlight, you can see that even though we had the default:group:fred:rwx acl rule, the mask for the file testfile has stripped the exec bit for us.

The SGID isn't really necessary, but I think it makes things a little tidier by keeping the group the same for all the files.


What all this boils down to is that 'ls -l' cannot be trusted when it comes to acls.
getfacl --tabular is a better choice.

I don't know enough about how samba does its user mapping to say how this approach would interact with it, but maybe something like this would work for you?

Anyway, I hope that helps, or at least gives you something more to look at.

Possibly not.

Yes, I understand that. I should have explained better that my beef with the executable bit is cosmetic.

Yes, I now remember reading that in the documentation, but the meaning went right through my gray matter.

Yes, this could make sense.

Probably true. On the other hand the cosmetic value of seeing the group set as desired is comforting. No harm, no foul and all that.

Yes, I can see that now with your explanation and a day away from the problem.

Bottom line: The plus sign in a directory/file listing is a warning that What You See Is Not Necessarily What You Get.

I have an hourly cron shell script that runs through my /home/Files directory to ensure I have the permissions set as I described (2775/664). Running this hourly script still helps because of the cp problem I described because an ACL does not seem to control or override the file permissions during a copy.

I don't know. I'm no Samba expert either. I suppose I can live with the obnoxious x bit. My hourly script will remove that. My need to have the group have write permissions is now controlled by the ACL. I realize this is hardly a perfect world, but seems to me that such a problem must have risen long ago and a solution should be available. Odd.

Just an interesting aside:

NTFS partitions mounted under linux, e.g., in Ubuntu, using FUSE, are mounted by root, and all files are listed with root permissions. Then if the user has sudo permissions, they will have read/write access, once they unlock the keyring. This may be a solution to your issue, since all users with sudo permissions for read/write access in Ubuntu FUSE can access the same files. Check it out.

The reason I suggest this approach is simply because of your mixed windows/linux environment, and the fact that granular sudo access is available easily within Ubuntu.

There are two issues: one is your use of NT4.0 servers, which AFAIK do not use NTFS, but this may work with FAT32 partitions also, I haven't checked. The other is how you would implement this in slack, but perhaps the unstable package branch in slack may have upgrades to HAL which would allow similar automatic mounting of NTFS or FAT32 partitions.

Best of luck figuring a solution to your problem!

The files are stored at /home/Files, an ext3 partition and shared through Samba to my virtual and real Windows machines. Mounting NTFS partitions was never a part of this discussion.

Sudo, sudo, sudo.... I run my boxes as root as often as I want. Been doing that for more than two decades. (Jumps into nearest tree, yells, and pounds chest....)

No Windows servers here in this discussion, only workstations. Windows NT4 uses NTFS-4 (NT File System 4).

There is no "unstable" branch in Slackware. There is the Current branch where testing is performed for the next release, but I don't know of any Slackers who would call that branch unstable.

Thanks for trying.

I believe it is possible to configure samba to NOT always set the execute bit or conditionally depending.
I recall being annoyed by it and currently have it configured to create new files without the execute bit.
Some more relevant settings and the ones I believe pertain to this issue are the map options.
map archive, map hidden, map system.
All these however determine how windows to unix permissions are mapped, may have missed some but don't think so:

acl map full control
create mask
directory mask
force create mode
force directory mode
force directory security mode
force security mode
inherit permissions
map archive
map hidden
map system

Hi Folks,

I work for an organisation where we need to transform ClearCase to Interity with the help of ACL security.

When I say Integrity, it has two ways to support, the check-in and check-out of files happens on PTC Integrity tool with securities on Unix as well as on Windows based systems.

I would like to know everything about the ACL security and its different ways to set the permissions etc.

I have been using linux/Unix from the past 5 years. Right now, I am on Unix Solaris platform and a perl script developer.

Please help/suggest to improve the knowledge about the ACL security and any suggestions to leverage the existing perl/shell script would be a great support.

Please post your thread in only one forum. Posting a single thread in the most relevant forum will make it easier for members to help you and will keep the discussion in one place. This thread is a duplicate, further discussion of this issue should continue here.