Hi.

I'm trying to manually simulate the sharing capabilities of a NAS system, i.e., NFS and Samba, since the use it would be to share some data between applications servers running under linux (especifically, RHEL 5) and the bunch of users in the AD. So, I created some data and exported the point for both NFS and Samba.

The basics are, that from a certain point, ACLs are set. The ACLs indicate, from AD point of view, an admin group with full control, and AD application group with read/write as needed (everyone is not used). From linux point of view, the user running the application server process is the owner of the tree, and a chown -R is done initially as you may guess.

The access is basically right, but I've found a major issue that has stopped me and I'm not sure how to go on. If a M$ user writes to the directory, the ACL does its work and the M$ ACL works properly. Also, the linux user, via ACLs, can take advantage of the inherited ACL. But if the linux user creates a directory, this is created with its umask and primary group, and doesn't inherit the ACLs, so from M$ clients the access in forbidden.

How can I get the linux user to inherit the ACLs of the parent directory when creating a new directory? Should I set anything in samba so the directories follow an inheritance?

Tomorrow I can provide the settings, if someone requests, but if anybody already set this and has come into the same issue (or knows how to solve), the configuration shouldn't be necessary.


Thanks in advance.

Try 'setfacl -d ...' , this will set default acl's which will be inherited by new directories/files

I replied yesterday, but for some reason, that reply has got lost. Anyway, I've advanced about the problem.

I've seen that my problem is about how the Extended ACEs (EAs) are managed by cifs clients, and this relies upon the management of the attribute (set via setfattr) user.SAMBA_PAI, so I've seen:
1) The posix ACLs are properly inherited
2) In a directory created by a cifs client, I can see the attribute via getfaddr -d <entry>, with non-human values
3) When creating the directory via linux, the attribute is not set. If after creating, I tweak inheritance from the XP workstation, then the attribute is added.

So, I have thought of two workarounds:
1) Samba team could offer an alternate way of handling EAs based on posix ACLs instead of the user.SAMBA_PAI attribute. This is supposedly more official.
2) Write a custom script to be run instead mkdir (it would be /usr/local/bin/mkdir) that acts as a wrapper of /bin/mkdir. This script, after doing the usual stuff (i.e., create the directory), could take care of the existing attribute and, if it exists, set it in the new directory with the same value.


I have written the script (at least for initial alpha testing) in bash and I'm going to test and keep working on it. I'll be glad to provide it to whoever requests it and also wants to play with it.

Any comments are welcome.

You should read up on what Netapp did with WAFL to allow Linux/Windows volume sharing, and also its limitations.

Can you please explain more clearly what you mean?

It seems like you're running into filesystem limitations, Netapp use a "filesystem" called WAFL on their appliances that can be tuned for CIFS and/or NFS access. From memory there are limitations when using shared mode, I don't think it's possible at the moment to provide all the native features.

hth

Have you considered having the Linux systems also use smb to access the disks? I think trying to use NFS & Samba on the same disks is fraught.

Yes, I've considered, but there are too many drawbacks (mostly due to the way apps themselves work).

- Security: while nfs is unauthenticated, cifs is not. This leads to have an administrative plaintext and unchangeable cifs password (security is ADS) in fstab. If there was some way to ensure that noone can reuse these credentials from anywhere else (cifs clients under the same or other server, or any cifs workstation).
- Multiple management per host. Every host having an appserver (and there are some), hosts many apps, and each has its own scope (i.e. mount point). This is, regardless nfs or cifs, difficult to maintain by itself, but nfs is less difficult for us (unix admins) to maintain.


You might think the general architecture of apps is wrong or should be changed/enhanced, but regardless that, I think that there should be a way to handle this situation. Currently, I think the situation can be simplified with "with my current setup, I've found situations where samba doesn't interpretate correctly unix acls". So, I believe that it's whether a samba bug, or something I didn't setup properly (in any of the layers), and I'd like someone to provide light about this.


The background of all this is that it's hard for me to believe there's no open source alternative (even hand-made as I'm doing) for expensive and propietary NAS solutions (al least for the basic sharing of the filesystems for both protocols). Of course, there are many features that a blackbox NAS provides, but any half-experienced linux admin should be able to mimic the basic features that are really used in a NAS (and what only the final users care) about providing nfs and nfs&cifs shares by using a nfs server daemon and samba, with at least some proper storage and its management.

I'd like to mention about this that I've done a sucessful advance about the functionality, from the app user point of view, without losing effective permissions, but it's not 100% perfect because the "automatic" inheritance is lost, but remaining the basic permissions.

I've got this by leaving "vfs_objects = acl_tdb". I've tried this setting with ext3 and xfs, and I've found no difference between both filesystems. I've also opened https://bugzilla.samba.org/show_bug.cgi?id=8353 for this.