samba - Mar 2005 - Os X and Win clients to SMB 3.0.10 server - how to hide ._ files from win clients only

Hello group,

I am working on a test installation of Samba 3.0.10 on FreeBSD 5.3 as potential
solution to some of our current file server problems.  One of the main ones
being good 'ole Win2000 Services for Macintosh - which we would like to dump
completely.  

Here's the situation.  We have a handful of Mac machines, all recently taken
to
10.3.7 (10.3.8 upgrade is pending) which currently connect to our windows file
server over AFP, which requires Win2K services for Mac in order to operate. 
This has worked fairly well in that the 'rfork' files (._filename.ext)
are not
required in order to maintain filetype data.

As I understand it - OS X when connecting with AFP assumes that it is writing to
an HFS/HFS+ share, and expects the file system to handle rforks, a job that is
badly taken over by win2k services for Mac.

When connecting with smb, OS X assumes that it is writing to any file system
*other than* HFS/HFS+ and invokes the Doubler features to generate these rfork
files.

Aside from my obvious file-migration issues that are going to be popping up (mac
users never consistently applied extensions to file names, many many file names
include the / character, etc.) I would like to find a way to hide these ._files
from my windows clients, without loosing the ability for OS X clients to view
them.  Our current policies are such that Windows machines are configured to
view "hidden" files, and this is unlikely to change. The OS X Finder
does not
show any '.' files by default - but the OS needs to read them in order
to access
the rfork data.

My initial thought was to use a simple veto on these to render them unavailable
to  user viewing or manipulation - which half worked.  Having them veto'd in
the
share  or global portions of smb.conf rendered them inaccessible to OS X as well
- meaning that all of those files (particularly ones without extensions) lost
their association data.

Could anyone point me to some information regarding managing these files in a
Windows/OS X environment?  Is there some way to base veto's on user or group
IDs? For example, could I generate a group for my mac users and then veto
._files for everyone except that group?

Since our Mac users access more than just their primary file share this would
eventually become an issue should we migrate more of our file server functions
to a Samba based solution.

My apologies for such rudamentary questions.  My attempts to search for this
information on the mailing list resulted in several - much more specific
problems that sound like post-setup type of issues.

Thanks,

--David
dbowsky (at) Nolo (dot) com

On Mar 3, 2005, at 7:29 PM, David Bowsky wrote:
> Could anyone point me to some information regarding managing these 
> files in a
> Windows/OS X environment?  Is there some way to base veto's on user or 
> group
> IDs? For example, could I generate a group for my mac users and then 
> veto
> ._files for everyone except that group?
You can include a modified smb.conf file from within the standard file 
to customize the behavior for different clients. Look at the man page 
for smb.conf in the section on "Explanation of each parameter" for the
parameter "config file" (listed alphabetically). Also look at the 
beginning of that man page (it's about 100 pages long!) under "Variable
Substitutions" to get an idea of the sorts of things you can use to 
differentiate between clients. For example, one of the variables is %a, 
which is supposed to expand to the architecture of the remote machine. 
I assume this would be "Samba" for a MacOS X machine (based on what it
says in the man page) and something else for a windows client.

The way it works is that if the name of a config file is given, but the 
file doesn't exist, it's ignored. Otherwise, the new file is loaded in 
place of the original. So you could try something like adding a line:

    config file = /path/to/file/smb.conf.%a

to your [global] section. Have the standard config file set up for the 
windows machines (with the veto to hide the ._files). Then make a new 
config file that is otherwise the same except without the veto for the 
MacOS X users and name it "smb.conf.Samba". That way, any client that 
looks like "Samba" OS type will get the modified config file and all 
others will get the original. It sounds like %a may not be the most 
reliable of the variables, but of any OS type, one running samba should 
certainly be correctly detected! In any case, once you see all of the 
variables that can be used to control this, your head will start to 
spin with the possibilities.

-- 
Patrick D. McSwiggen                            pat.mcswiggen@uc.edu
Mathematical Sciences                            513-556-4080
University of Cincinnati                         513-556-3417 FAX