Subject: authentication doesn't work with pre-asun2.1.4-37b.tar.gz

From: Frank Jördens <[email-masked]>
Date: Sun, 12 Nov 2000 18:43:12 +0100

Previously I was using netatalk-1.4b2+asun2.1.3 where it did work, now I
am trying to set up pre-asun2.1.4-37b.tar.gz to have the -mswindows
option, but the authentication doesn't work anymore. Users get a 'wrong
password' message if they try to login now. I am using the defaults in
the afpd.conf. When starting netatalk, the uams get loaded:

Nov 12 18:19:54 limedes afpd[2295]: uam: uams_guest.so loaded
Nov 12 18:19:54 limedes afpd[2295]: uam: uams_clrtxt.so loaded
Nov 12 18:19:54 limedes afpd[2295]: uam: uams_dhx.so loaded
Nov 12 18:19:54 limedes afpd[2295]: uam: "DHCAST128" available
Nov 12 18:19:54 limedes afpd[2295]: uam: "Cleartxt Passwrd" available
Nov 12 18:19:54 limedes afpd[2295]: uam: "No User Authent" available

Guests do see those volumes that are allowed for guests.

Also, now I am seeing a tmp volume (which corresponds to /tmp) which
wasn't there with the older netatalk version. How do I switch it off?

Any Ideas?

Thanks, Frank

---

From: "Alex Yu" <[email-masked]>
Date: Sun, 12 Nov 2000 18:40:46 -0500

hello,

can someone give me tips?  i want to hack the source that so that every
users will always have read/write permission to .AppleDesktop and
.AppleDouble.

Alex

---

From: andrew morgan <[email-masked]>
Date: Sun, 12 Nov 2000 17:22:00 -0800 (PST)

> users will always have read/write permission to .AppleDesktop and

Here's a crazy idea: how about giving your users permissions on those
directories in unix?  :)

Otherwise, it may take some work because afpd drops root priviledges and
becomes the logged in user.  You should be able to modify it to switch
back to root when needed, which is probably what you need to be
considering.

	Andy

---

From: "Alex Yu" <[email-masked]>
Date: Mon, 13 Nov 2000 08:56:00 -0500

> Here's a crazy idea: how about giving your users permissions on those

I know it's odd, but afpd doesn't seem to give people permission to
.AppleDouble / .AppleDesktop depends on its actual directory permission.
What I mean is if

  ~user1 owns by root
    /.AppleDouble owns by user1/group1 and have read/write permission.

afpd won't write resources in .AppleDouble because user1 doesn't have write
access to his root directory.

Alex

---

From: andrew morgan <[email-masked]>
Date: Mon, 13 Nov 2000 06:25:55 -0800 (PST)

> access to his root directory.

What is in your Applevolumes.default file for shares?

What are the permissions/ownership of that directory and its
.AppleDouble/.AppleDesktop directories?

Maybe there is a way around this that doesn't require changed afpd.

	Andy

---

From: "Alex Yu" <[email-masked]>
Date: Mon, 13 Nov 2000 09:44:51 -0500

> What is in your Applevolumes.default file for shares?

How about this, let me make an example.

in Applevolumes.default

/project "Projects" access=@group1

> .AppleDouble/.AppleDesktop directories?

drwxr-xr-x   2 root     root      4096 Nov 13 09:33 project

/project
drwxrwxr-x   2 root     group1    4096 Nov 13 09:34 .AppleDesktop
drwxrwxr-x   2 root     group1    4096 Nov 13 09:34 .AppleDouble
drwxrwxr-x   2 root     group1    4096 Nov 13 09:33 project1
drwxrwxr-x   2 root     group1    4096 Nov 13 09:33 project2

The way I want is to make afpd to check against permission on .AppleDesktop
& .AppleDouble.  Currently, afpd takes permission on /project to determine
whether or not it can write to .AppleDesktop & .AppleDouble.

Alex

---

From: "Patrick Peccatte" <[email-masked]>
Date: Mon, 13 Nov 2000 16:01:44 +0100

I try to build a Mac+Win file server on a Linux box using a directory both
shared as a Netatalk 1.4b2+asun2.1.1 volume and a Samba 2.0.7 volume. Now I
found 4 problems:

1) A Mac file with national chars (à, é, è, ù, etc.) is viewed as a strange
shortened name from Win clients. A solution has been given on this list
using iso8859-1 code page in the Netatalk and Samba volumes declarations,
but I was not able to run this solution correctly on my French systems.
2) Filenames longer than 31 chars which are allowed and managed by Win
clients are not seen by Mac clients.
3) "Lock" flag (from a Mac client point of view) and "Read only" flag (from
a Win client point of view) are not synchronized.
4) Last but not least: renaming, deleting, copying files from a Win client
are absolutly insane operations. When you rename a file using a Win client
for example, the renaming process does not rename the .AppleDouble
corresponding file, so the file losts its resource fork from a Mac point of
view.

My questions:
a) Is there any other problem using Netatalk and Samba sharing a same
directory ?
b) Is exist operational solutions to avoid these problems ?
c) Do you know if the future NTFS support on Linux will give a solution for
the point 4, allowing to store multiple file components (as Mac data and
resource forks) in "streams" of a same file (a technique used by all Mac
Servers running on NT box) ?
d) I imagine to manage separatly the Netatalk volume and the Samba volume,
linking them using symbolic links and a daemon:
let for example a Linux directory \data-a shared as a Natatalk volume 'data'
and another Linux directory \data-s shared as a Samba volume 'data'; \data-s
contains symbolic links on files which are in \data-a, and a daemon manages
the 1-1 correspondance between file naming conventions and modifications by
Mac clients in \data-a and file naming conventions and modifications by Win
clients in \data-s. Is it possible ? Is exists ?
---
Patrick Peccatte
Software: http://peccatte.karefil.com/Software/Software.html

---

From: "Jonathan Newman" <[email-masked]>
Date: Mon, 13 Nov 2000 07:57:07 -0800

> clients are not seen by Mac clients.

This is a limitation of both the MacOS and netatalk.  It has been
suggested that the names of files for files > 31 characters get
remapped.  This has a handful of issues associated with it, and is a
more complicated problem than it seems.

> a Win client point of view) are not synchronized.

This is a problem with Samba.  Samba maintains its own concept of file
locking, avoiding the native locking mechanisms for speed.  I believe
the Samba team has plans to change this.

> corresponding file, so the file losts its resource fork

I thought compiling Samba with the "netatalk" option solved some of
these issues.

> a) Is there any other problem using Netatalk and Samba

We use them here for the same shares.  We don't have a lot of
problems.  One of the "tricks" is to set up the veto files on Samba so
that the windows users don't accidentally delete the
.AppleDouble/.AppleDesktop/Icon files:

veto files = /.AppleDouble/.bin/.AppleDesktop/Network Trash
Folder/Icon?/TheFindByContentFolder/Temporary
Items/TheVolumeSettingsFolder/

> Servers running on NT box) ?

If I undersant correctly, you can use an HFS volume on the linux box
to accomplish exactly this.  I believe the .AppleDouble structures are
supposed to mirror the interface to the hfs volume manipulation of
resource forks.  Unfortunately, I don't believe there is support for
HFS+ which means only volumes up to 2GB volumes are supported.  I
don't know if this all is exactly correct, but it is what I have
surmised after looking through the netatalk code.

Jon

---

From: Matthew Keller <[email-masked]>
Date: Mon, 13 Nov 2000 11:02:11 -0500

> corresponding file, so the file losts its resource fork from a Mac point of

	compile Samba 2.0.5+ with the --with-netatalk flag.

> a) Is there any other problem using Netatalk and Samba sharing a same

	Lots of them.

> b) Is exist operational solutions to avoid these problems ?

	Nope.

> Servers running on NT box) ?

	The filesystem isn't the problem- The differences in locking and
permission masking are.

-- 

 Matthew Keller
 WebMaster, Interim Network Manager & 
   Host Systems Analyst
 Distributed Computing/Telemedia
 Information Services Division
 State University of New York at Potsdam
 
 Website: http://mattwork.potsdam.edu/
 PGP: http://mattwork.potsdam.edu/crypto/
 Webcam:  http://webcam.mattwork.potsdam.edu:85/

---

From: Frank Jördens <[email-masked]>
Date: Mon, 13 Nov 2000 17:28:07 +0100

> the Samba team has plans to change this.

What exactly is the problem with this? We have about 20 Macs and 10 PCs
here, and I haven't noticed any Problems, except for the charset mapping
issue which I am trying to solve with a current developer version of
netatalk (Netatalk 1.4b2+asun2.1.1 - which the original poster mentioned
- does not support the -mswindows option), namely
pre-asun2.1.4-37b.tar.gz, which unfortunately has a broken
authentication module, it seems (at least my efforts to get it to work
so far have been futile). the newer versions 38b and 39b have exactly
the charmapping broken (I did verify that for 38b, not for 39b, which is
just hearsay).
> I thought compiling Samba with the "netatalk" option solved some of

What effect does that have exactly (we haven't noticed any issues with
this so far)?

- Frank

---

From: David R Bosso <[email-masked]>
Date: Mon, 13 Nov 2000 08:49:18 -0800

--On Monday, November 13, 2000 5:28 PM +0100 Frank Jördens 
<[email-masked]> wrote:

> What exactly is the problem with this?

In my testing I was able to open Word, Excel, and FileMaker files via a PC 
over Samba, and Mac over Netatalk, and make changes simultaneously.  This 
resulted in some strange results depending on what client saved first/last, 
and I was able to get the Filemaker file into some wierd states.

-David

---

From: "Jonathan Newman" <[email-masked]>
Date: Mon, 13 Nov 2000 08:52:21 -0800

> here, and I haven't noticed any Problems, except for the

If a file is considered "locked" on windows, it still may be
manipulated by the mac.  This is a real problem with any application
that maintains a "database" (I use this term loosely) on the server.
Locking is not atomic with the methods that Samba employs.

> What effect does that have exactly (we haven't noticed any

Hmmm.  Well, I just looked through the Samba 2.0.7 code, and it looks
like it doesn't do anything.  There are routines to maintain the
.AppleDouble information through moves/renames, but as far as I can
tell, they aren't used anywhere.  :(  I guess I should be more
informed before I start handing people advice.

Jon