Subject: Samba and Netatalk

From: "Daniel E. Lautenschleger" <[email-masked]>
Date: Tue, 6 Mar 2001 15:57:00 -0600 (CST)

Would anyone care to comment on experiences they've had sharing data out
on a volume that was accessed by Netatalk and Samba? Any glitches? No
problem, go ahead and do it, your nuts, dude..., etc...

Thanks. I have a dream that I can take one of our NT file servers and
replace it with a Linux/Samba/Netatalk box. What a fine realization that
would be...

Thanks.
-Dan

---

From: Richard Michael <[email-masked]>
Date: Tue, 6 Mar 2001 17:56:01 -0500

> problem, go ahead and do it, your nuts, dude..., etc...

I've been doing this for awhile.  I have a stable netatalk/samba server
at netatalk 1.4b2+asun.  No trouble; unless my users aren't telling me.
Read the mailing lists - there a --with-netatalk config time option (not
in the build docs that I could see, but it was covered on the mailing
list IIRC).  --with-netatalk is currently an experimental hack, if I
remember, it forces samba to move the .AppleDouble entries if a PC user
moves files around from the PC (so as not to pooch appleshare side
stuff).  Don't know how reliable it is, I only included that option on
the most recent server I config'd and it hasn't been tested thoroughly
yet.

Build it and try it out.

Otherwise, nope you're not crazy.  It's pretty nice.  Just be aware of
the filename issues and that Mac people should add the appropriate
suffix to files they expect to dclick on a PC.

Incidently, if --with-netatalk destroys something or is generally nasty,
let me know :)  There's too much traffic on the samba lists to subscribe
:)

Ciao.
Rich

---

From: David R Bosso <[email-masked]>
Date: Tue, 06 Mar 2001 15:33:14 -0800

> the most recent server I config'd and it hasn't been tested thoroughly

I've been researching this for a while, and the biggest problem I've seen 
is incompatible locking.  Simultaneously opening a datafile from both a 
Samba connected PC and a Netatalk connected Mac can cause strange things to 
happen if they both try to modify the file.  There are no errors, and the 
file can easily be corrupted.

AFAIK the --with-netatalk in Samba does nothing.  Unless something has been 
changed recently, it was a feature that was never finished.

-David

---

From: Matthew Keller <[email-masked]>
Date: Tue, 06 Mar 2001 19:22:58 -0500

> problem, go ahead and do it, your nuts, dude..., etc...

	Samba and Netatalk play completely wonderfully nice together... As long
as you don't want users from both platforms simultaneously being able to
access the same files, that is. There are severe locking issues (even
NT/2000 doesn't handle it all that great). But if you're doing something
like a Home Directory server (where, theoretically, no one will ever be
on two computers at the same time, let alone 2 computers of different
platforms at the same time) it works really really well. I've got
serveral very large Netatalk+Samba installations out there (clients),
and even a couple here @ the College.

-- 

 Matthew Keller
 Enterprise Systems Analyst
 Computing & Technology Services
 Information Services Division
 State University of New York at Potsdam
 
 Website: http://mattwork.potsdam.edu/
 PGP: http://mattwork.potsdam.edu/crypto/

---

From: Ryan McBeth <[email-masked]>
Date: Wed, 7 Mar 2001 07:09:11 -0500

Daniel,

	The two seem to co-exist together pretty well.  Rich made a 
few valid points with .AppleDouble files.

	However, there is one thing that you may want to bring up in 
regards to Windows and Linux users.  You need to let them know that 
they can't create files greater than 32 characters or the Mac users 
won't be a able to see them.  And you will get holy hell from your 
Mac users when they call you and day "Bob said that he put the file 
on the server, but I can't see it, is the server broken?"
	So, you may need to do some social engineering with your 
Windows and Linux users to make sure that they understand the 
limitation.  They will forget about it anyway, so make sure you have 
them sign something.  :-)  Can you tell I've been an Admin for way 
too long?

	Ryan

>replace it with a Linux/Samba/Netatalk box. What a fine realization that

__________________________________
Ryan McBeth
Systems Administrator, Mobius New Media
Voice: (302) 475-9880 x11
FAX: (302) 475-9894
www.mobiusnm.com
__________________________________
The secret to not getting burned out is to play at
working hard, and not taking things too seriously.
- Linus Torvalds

---

From: Tihen <[email-masked]>
Date: Wed, 7 Mar 2001 14:54:33 +0100 (CET)

I have had only minor problems -- if someone uses both sometimes the Mac
has a hard time reconizing what the files are.  But I think the solution
is to update the AppleVolumes (or something like that).  

I recommend -- "Go ahead [make my day]."

Bill

---

From: "Marc J. Miller" <[email-masked]>
Date: Wed, 07 Mar 2001 08:46:50 -0800

There is some sort of enable-netatalk-compatibility (or something similar 
to that) option in Samba which is supposed to, I repeat *supposed to* make 
it easier for netatalk to understand the file types.  But I've never tried 
it and I've heard some say that it doesn't work and they can't figure out 
what that feature is supposed to be for.  Might be worth investigating, though.

---

From: Frank Joerdens <[email-masked]>
Date: Wed, 7 Mar 2001 21:21:02 +0100

On Wed, Mar 07, 2001 at 07:09:11AM -0500, Ryan McBeth wrote:
> won't be a able to see them.

AFAIK it's actually 27 characters?! Dunno off the top of my hat where
it's documented  . . . I can dig it up if it's interesting and if no one
else remembers . . .

Regards, Frank

---

From: Frank Joerdens <[email-masked]>
Date: Wed, 7 Mar 2001 21:31:26 +0100

> replace it with a Linux/Samba/Netatalk box. What a fine realization that

Make sure that you're running a version of netatalk that has working
codepage support (the current snapshots are broken in this regard, AFAIK)
if you want your users to use German umlauts and such in their
filenames. Then you need to configure both Samba and Netatalk to use the
same codepage. Current versions also have a mswindows options which
disallows the creation of filenames containing the characters

/\:*?"<>|

which the PC can't deal with (my PC actually crashes when trying to
access a file containing ':' that was created on the Mac).

I'm still looking for a version of Netatalk that has _both_ working
codepage support and a working mswindows option . . . which would really
resolve all the problems we've had.

The locking issue is another matter (see below in this thread).
Interestingly, we haven't come across a single incident of this being
a problem in about 6 months of running Netatalk/Samba in a Network with 10
Macs and 5 PCs.

Regards, Frank

---

From: Frank Joerdens <[email-masked]>
Date: Wed, 7 Mar 2001 21:35:17 +0100

On Tue, Mar 06, 2001 at 07:22:58PM -0500, Matthew Keller wrote:
[ . . . ]
> NT/2000 doesn't handle it all that great

Please explain. I've kinda regretted using Netatalk/Samba because of
this and troubles with the mswindwos/codepage options. If NT/2000 has
trouble with locking too, that would be a relief!

Regards, Frank

---

From: "Bruce A. Burdick, Jr." <[email-masked]>
Date: Wed, 07 Mar 2001 19:44:54 -0600

> access a file containing ':' that was created on the Mac).

How did you create a filename with ':' in it? For as long as I can remember,
every time I type a ':' in a filename, the Finder replaces it instantly with
a '-'. The Mac uses colons the same way *nix uses '/' or DOS/Windows uses
'\' -- to terminate directory names in file paths. They are gracefully
disallowed in filenames.

-B...

---

From: Frank Joerdens <[email-masked]>
Date: Thu, 8 Mar 2001 14:55:13 +0100

On Wed, Mar 07, 2001 at 07:44:54PM -0600, Bruce A. Burdick, Jr. wrote:
[ . . . ]
> '\' -- to terminate directory names in file paths. They are gracefully

For the first few weeks of running the Netatalk/Samba combination, I
didn't have the codepage support switched on (didn't know about it or
couldn't get it to work, or something in between). The files that where
created in those first few weeks appear with ugly things like '9:' in
their names where the Mac users used umlauts. Now, with codepage support
enabled, i.e.

character set = iso8859-1

in /etc/smb.conf

and e.g. 

/mnt/zeug	zeug	codepage=maccode.iso8859-1

in /etc/atalk/AppleVolumes.default

if I create a Folder with '/' in its name on a Mac, it will show up as
':2f' on the PC.

Regards, Frank

---

From: Frank Joerdens <[email-masked]>
Date: Thu, 8 Mar 2001 16:50:48 +0100

On Thu, Mar 08, 2001 at 02:34:17PM +0000, Niall O Broin wrote:
[ . . . ]
> On the PC which is the server, do you mean ? Because you won't see :2f in a
> 'doze Explorer list - it'll mangle the filename to something with a ~ in it.

No, I mean on my NT box (NT 4.0 Workstation SP 6a) I see :2f in the
filename served by the Netatalk/Samba Linux PC. Trying to open a file or
folder with somthing like this in it doesn't always crash my NT box;
most of the time it will just say that the file does not exist. Quite
often though, I get a blue screen of death, and I need to reset my NT
PC (no graceful recovery possible). I haven't been able to figure out
exactly under which circumstances the crash occurs but it always happens
when I try to access funny folder or filenames.

Regards, Frank

---

From: Niall O Broin <[email-masked]>
Date: Thu, 8 Mar 2001 14:34:17 +0000

> > '\' -- to terminate directory names in file paths. They are gracefully

The filename with ':' in it is simply created by creating a file on a Mac
with some character which is mapped e.g. / (maps to :2f), which cannot be in
a Unix filename for the reason you already mentioned i.e. it is the
directory separator.

Regards,

Niall  O Broin

---

From: Matthew Keller <[email-masked]>
Date: Thu, 08 Mar 2001 11:41:48 -0500

> trouble with locking too, that would be a relief!

	Albeit better than the NON-EXISTANCE of shared locking between
Samba/Netatalk (although the new Samba has a locking API, so
theoretically any program can use its locking API to "stay safe" with
Samba), NT/2k still do not lock well between the two platforms. There is
no way to lock parts of a file,  and write-locks don't exist, so both
plats can simultaneously write to the same file and possibly corrupt it
horribly.

-- 

 Matthew Keller

---

From: Chris Harwell <[email-masked]>
Date: Thu, 8 Mar 2001 12:17:07 -0500 (EST)

> plats can simultaneously write to the same file and possibly corrupt it

cool. then do i understand correctly that we could patch netatalk to use
samba's locking API thus preventing this file corruption?

i'd like to lean more about this.  where would i look to lean more about
this?

what does linux do in terms of file locking? is there a level of
abstraction above specific filesystems and file sharing protocols?

what are the options for getting locking to work with
local access to the file system + NFS + samba + netatalk?

thanks,

-- 
chris
[email-masked]

---

From: Danny Sauer <[email-masked]>
Date: Thu, 8 Mar 2001 11:54:13 -0600

> local access to the file system + NFS + samba + netatalk?

There was a whole thread on this a few months back (less than 6 mo ago, IIRC)
which might be a good place to start looking.  It sticks in my mind that there
were a few people who were either working on a similar project or were willing
to contribute, but that might just be wishful thinking on my part.

I'll bzip2 my mbox format discussion list archive and email it to you if you
can't find an archive, but it seems like the groups were on-line somewhere.
I don't know where, though.  I'm sure someone does... :)

--Danny

---

From: Matthew Keller <[email-masked]>
Date: Thu, 08 Mar 2001 14:17:12 -0500

> samba's locking API thus preventing this file corruption?

	The new Samba 2.2 locking API is provided via a separate library, that
will allow for other server-type applications to, in effect "share"
locks, or at least honor each other's locks. Unfortunately, because of
what a Windows client EXPECTS when it opens a file on a server as
opposed to what a Mac EXPECTS when it opens a file on a server, this may
not prevent ANYTHING bad from happening. Macs are very sensitive to
"permission" changes after a file is opened - If when the file was
opened the Mac was given write permission, it expects the ability to
write to the file at any time until IT closes the file - This is a bad
assumption (just one of many), and will most probably collide with ANY
collaborative locking mechanism/API.

-- 

 Matthew Keller