0

I've got a local development web server running Ubuntu. I also have an iMac running OS X 10.6 which I use a client and is my development machine.

I'm currently have Samba server installed on my Ubuntu server. I have shares setup for all the website directories.

I then use my Mac and Coda to edit the files via their shares.

This generally works really well but I noticed that my Mac was writing loads of resource fork ._filename files everywhere. I found out the following about the files:

These files are created on volumes that don't natively support full HFS file characteristics (e.g. ufs volumes, Windows fileshares, etc). When a Mac file is copied to such a volume, its data fork is stored under the file's regular name, and the additional HFS information (resource fork, type & creator codes, etc) is stored in a second file (in AppleDouble format), with a name that starts with "._". (These files are, of course, invisible as far as OS-X is concerned, but not to other OS's; this can sometimes be annoying...)

Does anyone know of a way of sharing files between a Mac client and a Linux server that is most compantable between the two operation systems?

Ideally it needs to support the HFS filesystem so that the resource forks are not created and it also needs to support the permissions between server and client.

3 Answers 3

1

Netatalk is your answer.

It can take some time to get to work, because of the encrypted authentication required by newer versions of OS X. It is doable though, and I have done it twice.

From my own notes on this - might be a bit messy:

afpd.conf must contain - -tcp -noddp -uamlist uams_dhx2_passwd.so - the uams_dhx2_passwd module is important, to allow the authentication.

it will not compile without the necessary packages on the system, it will just silently not compile it, som make sure, that they are there.

$ ./configure --enable-redhat-sysv --prefix=/data/software/netatalk

Version: 2.2.3

AppleVolumes shares are made like:

/data/shared/    ShareName allow:user1,user2 cnidscheme:dbd options:usedots,upriv dperm:0770 fperm:0660

The users are system users and the permissions of the client will be those of the user they are authenticated as.

In order to broadcast to the network, use Avahi. This is the afpd service definition:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">%h</name>
  <service>
    <type>_afpovertcp._tcp</type>
    <port>548</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=Xserve</txt-record>
  </service>
</service-group>

I hope that made just a bit sense. It's taken from my own notes (which I happen to keep in markdown), so it's not really meant for anyone else but me. I hope it makes enough sense for you to use though.

0

You can force Samba to hide these dot files for other SMB clients with the option

hide dot files = yes

in your smb.conf.

This works reasonably well in regard to hiding the files (as long as users don't tell the Windows explorer to show them hidden files) but this doesn't solve the fundamental problem, as the pair of file and corresponding dot file tend to get out of sync quickly when non Mac OS systems are involved. This happens when you rename, delete or move a file in Linux or Windows and the dot file will not be changed accordingly.

To really solve the problem years ago, I had to switch to MacOS X server on the backend, but that has some other drawbacks and I am not sure I would do this again.

0

What about using the "veto files" directive in samba?

Something like:

[sharename]
 ... other settings...
Veto files = /*._*

I've never used it but it should work :)

ref: http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#VETOFILES

1
  • 1
    wouldn't that stop any file with ._ in its name from being written? I think you want /._*
    – Bill Weiss
    May 16, 2012 at 1:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .