Subject: [netatalk-admins] samba/netatalk

From: Wagner One <[email-masked]>
Date: Fri, 22 Jan 1999 14:13:22 -0500

Howdy,

I've been happily running netatalk for quite some time now. I would like 
to set up an area wherein mac and pc users can share files occasionally. 
Currently, I do not run samba (I guess that is what I need to share part 
of the disks to pc users). Would someone mind giving me a quick rundown 
of what I would need to do to set these two systems up together? I've 
seen talk occasionally regarding this subject, but would like to hear 
from someone doing it to find out success stories and/or problems of them 
coexisting, etc.

Thanks,
Mike

--
Mike Wagner - A bad Dead show is better than a good day at work...
[email-masked], [email-masked], [email-masked]

---

From: PayPC System Mail Subscriber <[email-masked]>
Date: Sat, 23 Jan 1999 16:42:45 +1000

Wagner One said in [netatalk-admins] samba/netatalk at 23/Jan/1999 (Sat) 
05:13:22.

> from someone doing it to find out success stories and/or problems of them 

Well, I run samba 1.9.18p10, and netatalk asun2.1.2.... they work rather well 
together, though I recommend doing the Network Trash workaround [making the 
Net Trash directory read-only, and pre-creating individual trash folders 
owned by each user account, mode 0600].

They co-exist quite well, but I have some advice:

1) Setup your .ext mappings correctly, and be SURE .pdf files are *NOT* 
mapped to 'TEXT', but rather 'PDF ' [treat all pdfs as binaries, even if 
they're ASCII encoded -- Postscript is CRLF format tolerant anyway].  If you 
use Word 5.1 (as we do, eschewing the viral and bloated Office 97/98 garbage, 
do setup .mcw as "Word pre-6 for Macintosh" and educate your Winbloze users 
to employ that extension for Word 5 files.  (You cannnot prevent them from 
using their office 97 crap, so let that be .doc)

2) The only real "problem" with file interchange [aside from the app version 
issues themselves] tend to be with text files.  If you use BBEdit on the 
Macintosh, you'll never have a problem.  Likewise, on the PC, using PFE or 
UltraEdit, you are fine.  "Problems" start when you use dumb text programs 
like Simpletext on the Macintosh, or Notepad on the PC.  If you also use 
"smart" text tools, then I'd actually recommend setting .txt to a BINARY 
transmission mode [that is, never convert CRLFs].

I'll paste my original posting to this mailing list on the interchange issues 
of text files:

----------- Repasting -----------

Hrm, I guess I've been lucky (or I setup things correctly)... but I don't 
have any file translation issues, EXCEPT for text files (more later).  BTW, I 
recommend you setup PDF files as "PDF " "CARO" *NOT* the normal TEXT/CARO.... 
many PDFs are not TEXT, and in my experiences of dealing with hundreds of 
web-borne (as well as locally generated (Distiller) PDF files, even the text 
ones are OK if treated as "binary" types.

Anyhow, my text file issues are follows:  I have samba/mac/linux shared 
zones.....  I'll summarise with a Matrix:

                  Creator
             UNIX   +  MAC    + SAMBA/PC
Accessor  +----------------------------
UNIX      !  OK        OK       MAYBE(2)
MAC       !  OK        OK       NEVER(3)
SAMBA/PC  !  MAYBE(1)  MAYBE(1)  OK

(1) Most programming editors (PFE, say) are tolerant of alternate platform 
text line ends.  Most "dumb" DOS tools can't deal with it.  I'm not that 
worried about this "dysfunction".

(2) This one is also pretty minor...  Most unix tools seems to ignore the 
extra character, though some display the CR as ^M (some text editors do) -- 
others like joe happily munch them silently.

(3) This is the annoying one.  ALWAYS end up with double-spaced text when 
accessing PC-created text objects.  This would be a minor annoyance at 
best... EXCEPT I happed to use CSV (Excel-type command-separated-values), 
which gets a bit damaged in the translation (well, not data-loss damaged, but 
annoying "double-spaced" spreadsheets, which most of my users require a 
person like me to "undo").

The long and short of it is that MAC<->UNIX, things are pretty happy.  It's 
when you have SAMBA/PCs into the mix, the shit hits the fan.  (Isn't that 
always the case?)

I know the problem is this: PC's use CR/LF, and the translation in 
netatalk+asun only converts the LF->CR... which leads to the double-spacing I 
observe - that's not rocket science.  I also know where the translation code 
is performed - but I have a worry/question... what if I 'eat' the LF of a 
detected CRLF pair (just passing CR's unmodified) in a text file stream?  I 
worry because the file advertises itself as say, 2000 bytes, but in actual 
fact would be "smaller" because of the eaten LF's.  Replacing it with a NUL 
isn't the right approach either, because some apps go psycho when binary-like 
data is encountered in an otherwise ASCII stream.

----------- End of Repasting -------------

3) *DO* setup your samba shares to both "veto" and "hide" files....  (to 
conceal the .AppleDouble and other "crap" that netatalk makes to create the 
2-fork files and stuff on unix systems.  They only confuse winbloze users, 
and tempt them to "delete" them, which is BAD if the files are Macintosh 
resource-laden files such as applications.

I *highly* recommend you segregate application shares, however. (Make a 
winbloze only one for samba, and a netatalk only for Macintosh).  Use the 
shared zones for data/scraps/Public common usage, really.  Things get weird 
when a windoze user starts browsing through Macintosh applications things. 
(no .ext, etc)

Here is my veto/hide list (used for samba in smb.conf, in the [global] 
section):

   veto files =  
/.?Desktop/.HoldDirectoryFinderInfoForMacNFS/.finderinfo/*Deskt
op DB*/resource.frk/.AppleDouble/.bin/.AppleDesktop/Network Trash 
Folder/Icon*/*
OpenFolderList*/
   hide  files   =   /.*/DesktopFolderDB/Trash-For%m/resource.frk/*Desktop 
DB*/*
Desktop DF*/*OpenFolderList*/*Network Trash Folder*/Network Trash 
Folder*/Icon*/
%Icon*/.AppleDouble/

Also, for sanity's sake, *DO* enable "delete veto files = yes", otherwise if 
a Winbloze user tries to kill an otherwise empty directory, they'll get very 
mysterious "that directory isn't empty" errors.... (the .AppleDouble stuff 
wouldn't be seen because it's hidden/veto'ed, but it'd prevent the deletion 
from occurring).

Those are the major issues I've encountered and had to deal with.  Generally 
speaking, file locking just works, though is often inelegant in its 
user-feedback.  I've never lost data, but had programs issue strange errors.  
So if different users attempt to edit the same file (one on samba, one on 
netatalk), the unix file locking prevents anything really nasty from 
happening... though since it's a "lower-level" error condition that 
guardposts it, either server kinda panics a bit and returns status codes that 
often cause "alarm" in the users' clients.   

Also one more thing... it would be VERY NICE for netatalk asun to have some 
of the group force and mode force directives samba has.  For shared areas, it 
would be nice to clamp the created files' groups and modes to smooth things 
like permissions... I do often have to waste my time fixing permissions 
issues in shared areas, and making entries "sticky" doesn't always fix the 
problems.

BTW: Samba 2.0 was just released...  it should offer an even more mature 
level of NT Domain integration, and have even more configurability.  Samba is 
a shining star for configurability and cross-platform compatibility.  And 
Adrian's patches to netatalk make the possibility of a largely painfree 
cross-platform server solution that's just plain fast and reliable more than 
a dream, but a useful and well-behaved reality.  Bravo to both teams.

Good luck!
=Rob=