Archive for ‘Samba’ Category
Browse:
Samba »
Subcategories:

This took a while to figure out, mainly because I’m a unix guy trying to “figure out” Windows Server and it’s archaic ACL system and the fact that ACL’s/attributes under OSX are just insane. The main issue I had with all the other recipes on the net describing this process was that it did NOT work for OSX/Finder. When users transferred the files, Finder was not able to strip off it’s “in-use” attribute from the file once copied to the destination. This would leave files in limbo (greyed out) and no one could touch/access them from another Mac until I stripped the “in-use” attribute off manually. Normally SMB capable NAS’s ignore Finder/OSX attributes and this does not happen, but FS7500 is “mac friendly” and preserves the attributes so we had to figure out a way to give Finder enough rights to be able to strip the attribute off once the file was copied.

The core idea here is that you have a windows share (\\elm\DROPBOX in my case) which has a bunch of subfolders under it, one per class (they are in the form of BDCxxx.yyy in my case). What we’re trying to do is give AD users who are in AD groups (also called BDCxxx.yyy in my case) which represent classes enough permission to get inside \\elm\dropbox and see the name of the subfolders and be able to drag files onto the appropriate class subfolder (BDCxxx.yyy), essentially submitting their assignment. What we don’t want to let the users do is to peak inside those subfolders. It’s the equivalent of a “write only” group permission on a folder (no execute or read bit) in unix land. We also want to have our instructors be able to access everything in the DROPBOX share, so we use a group called DropBoxMasters for that purpose.

For the sake of this example I will use the student/class group BDC974.011 which the students belong to and DropBoxMasters group for our instructors. So here we go:

1) We obviously need a share. If you’re using a FS7500 NAS you just create the share and that’s it, no sharing permissions, everything is controlled by Windows ACL’s. If your share is on windows then I guess you can give full control sharing permissions to Domain Users. Once this is done we access \\elm to set the Windows permissions on DROPBOX share.

2) For DROPBOX we need the following permissions to be set to Allow and Apply it to “This folder only”: Traverse folder/execute file, List folder/read data, Read attributes, Read extended attributes, Read permissions. This will allow our BDC974.011 students to see the content of this folder (i.e. the subfolders, one per course). Remember that you need to create this permission set for each individual course/group/class. And remember to apply to “This folder only”.

Screen Shot 2013-02-28 at 3.11.57 PM Screen Shot 2013-02-28 at 3.12.15 PM

3) Still on DROPBOX share permissions we want to setup the DropBoxMasters group. This one is easy since it’s “Full control” permission that applies to “This folder, subfolder and files”. Easy :-)

Screen Shot 2013-02-28 at 3.16.58 PM

4) Before we go on, a note about the above process. In the permissions/Advanced security settings you should only have the “class/course” groups, the DropBoxMasters group, SYSTEM group (with full control) and Domain Admins (with full control). Next we want to create the subfolders inside DROPBOX, one subfolder per course/class (BDC974.011 in my case). Permission wise we want to setup the following permissions for the group that matches our course/folder (i.e. the example screen shots here are for group BDC974.011 on subfolder \\elm\DROPBOX\BDC974.011). We need the following permissions to be set to Allow and Apply it to “This folder only”: List folder/read data, Read attributes, Read extended attributes, Create files/write data, Create folders/append data, Write attributes, Write extended attributes, Read permissions.

Screen Shot 2013-02-28 at 3.31.53 PM Screen Shot 2013-02-28 at 3.32.07 PM

5) Still in the security settings for the course subfolder we need to add “CREATOR OWNER” to the list of permissions (This is a built-in windows entity) and give it the following permissions for “Files only”: basically all the allow check boxes EXCEPT the following (leave unchecked)……Full control, Change permissions, Take ownership. Remember these permissions are to be applied to “Files only”.

Screen Shot 2013-02-28 at 3.37.06 PM Screen Shot 2013-02-28 at 3.37.18 PM

That’s it…..Now just keep repeating this for all your courses/groups.

._ resource fork files don’t work properly in OSX 10.6 Samba……

datePosted on 23:36, January 29th, 2010 by Many Ayromlou

Well the title is a bit misleading…..here are the details. I found out that if you have a NTFS native shared directory on your server, everything works fine as long as you’re using OSX 10.5 (Leopard) or below as a client. You can move files from Leopard and/or Tiger clients to the share and as long as you don’t mind the ._ files everything works.

Well something new has been introduced in Snow Leopard that kinda breaks this. If you have a Snow Leopard client machine accessing a NTFS native shared directory (via smb), by default the shares are mounted with the new xattr (Extended Attribute) feature, instead of those “old” ._ files. This messes everything up if you’re in a mixed environment with 10.4, 10.5, and 10.6 clients all accessing files in a NTFS native smb share.

Snow Leopards version of samba will read those old resource fork files, but files uploaded or modified by the Snow Leopard client will be unrecognizable by the older samba clients (10.5-) as far as the resource fork goes. This introduces some problems with programs that use the resource fork to store information.

All this headache is related to the ‘NTFS Streams’ feature of SMB mounts, so if we disable that, everything goes back to normal. To do this you have to create a file named /etc/nsmb.conf on all your 10.6 clients with the following contents:

#######
[default]streams=no
#######

Getting Samba to work properly with SuSE’s Firewall…

datePosted on 19:57, November 1st, 2007 by Many Ayromlou

Here we are again and I have to sadly say…..yet another OS (which I also love) that does not do what it promises. I know that you can do some major iptables kungfu under linux through command line, but when SuSE/Novell tries to sell you Yast as a graphical admin interface they should atleast check to make sure things are working properly.

Samba works under SuSE 10.x, and even with the firewall turned on the machine can act as a member of a Windows domain/workgroup. The problem though, is not with using Samba and having the firewall turned on. The problem is having Samba do more than just act as a member of the domain. We have a SuSE 10.1 machine that is part of our AD domain (spanning 3 subnets) and we also like it to be our local master and preferred master on the local subnet. It has one NIC active (ie: direct connection, with no NAT) and iptables firewall is active on that NIC. The problem is that the firewall rules that Yast2 creates are too restrictive (ie: if you just go to Yast2 and add Samba services as a allowed service). 
Here is how you can fix this with a bit more effort:
  • Setup the firewall with allowed services you like to punch through (ie: ssh, ftp and alike). Include Samba Server in the list as well under allowed services.
  • Start the Firewall, at this point the basic samba stuff is working (ie: you can browse), but you more than likely can not do anything more in terms of domain participation.
  • From the Yast2 interface go to System> /etc/sysconfig editor screen
  • Goto the section Network> Firewall> SuSEfirewall2
  • ADD the following service names to appropriate sections ONLY if they are missing
  • Under heading FW_SERVICES_EXT_TCP make sure you have the following:

microsoft-ds netbios-dgm netbios-ns netbios-ssn

  • Under heading FW_SERVICES_EXT_UDP make sure you have the following:

netbios-ns

  • Under heading FW_ALLOW_INCOMING_HIGHPORTS_TCP make sure you have the following:

microsoft-ds netbios-ns

  • Under heading FW_ALLOW_INCOMING_HIGHPORTS_UDP make sure you have the following:

microsoft-ds netbios-ns

  • Under heading FW_ALLOW_FW_BROADCAST_EXT make sure you have the following:

netbios-ns netbios-dgm

Now you’ve got the right holes punched through the firewall so click Finish and enjoy. You can now go back to the Samba config and make changes to become a serving member of your domain/workgroup.