Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Secure backup (with resource forks) to Linux boxes UNIX
I've seen many hints relating to backup to Linux, we always seem to stumble on the resource forks. I am using a Linux server, SSH, and Samba to share a filesystem to my Macintosh via an encrypted connection. If you want to learn how to do that, then read on...

To simply use an existing network share to backup your data, use this:
# sudo ditto -V --rsrc SRC-DIR /Volumes/NETWORK_DISK
where SRC-DIR is what you want copied, and NETWORK_DISK is the name of the network file system that you have mounted.

In order to set up an encrypted connection, you will need Administrator privileges on the Linux server and your Mac client. As I document it here, this will BREAK any other SMB connections! So you might want to do this only as a temporary measure.

If you're still reading... my Samba setup on the Linux server...

    hosts allow =
    security = user

    path = /path/to/large/disk
    writeable = yes
    only user = yes
    valid users = backup
Then I create a user called "backup" via the smbpasswd command on my Linux box:
# smbpasswd -a backup
New SMB password:
Retype new SMB password:
Start your samba server; I typed # /etc/init.d/samba start to start mine. On the Macintosh, you need to set up an SSH tunnel to encrypt the connection to your SAMBA server. As I document it here, this will BREAK any other SMB connections! So you might want to do this only as a temporary measure.

Macintosh client SSH Setup:
# sudo nohup ssh -2 -q -f -N -g -L  139: root@linux-server
Now in the Finder, you can add a Connection to the following share: smb://localhost/backup. See, that's the real trick -- you let SSH tunnel a connection to the SMB port on your Linux server to a local port on your macintosh. Then you tell the Finder to connect to that (local) port -- that's why you use "localhost" as the server name.

We jump through all these hoops because for Linux servers, the most reliable network server setup seems to be Samba. And I wanted to encrypt the data stream between the computers. Note: It is rather slow. After you get the share set up, you might just want to try a Finder copy: drag folders to the appropriate icon in the Finder. Or use psync.
  • Currently 3.33 / 5
  You rated: 4 / 5 (6 votes cast)

Secure backup (with resource forks) to Linux boxes | 4 comments | Create New Account
Click here to return to the 'Secure backup (with resource forks) to Linux boxes' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Secure backup (with resource forks) to Linux boxes
Authored by: olivesoft on Apr 30, '04 02:26:17PM

My question is: "Why use SAMBA at all?"
Why not use NFS? Netatalk even.

I tend to think of [Mac] OS X as Linux with QA and Taste.
-James Gosling, Java Architect

[ Reply to This | # ]
Secure backup (with resource forks) to Linux boxes
Authored by: ratti on May 05, '04 05:07:07AM

Since NFS has no individual authentification but only per-host.
NFS is crap when you try to authenticate per-user.

[ Reply to This | # ]
Secure backup (with resource forks) to Linux boxes
Authored by: jms1 on May 01, '04 02:13:12AM
even better... if you're creating a new archive rather than updating an existing archive, you don't have to deal with samba or nfs at all.
sudo ditto -c -z --rsrc {source} - | ssh user@server 'cat > backup.cpio.gz'

[ Reply to This | # ]
Secure backup (with resource forks) to Linux boxes
Authored by: sjk on May 01, '04 04:24:02AM

Ahh, I had just considered posting a similar suggestion but hadn't figured out the details of how best to extract data. Using gzcat and cpio from the command line there's an issue with resources forks being restored with ._ prefixes that differ in size from the original resource fork, like:

% ls -l bin/buildDMG/..namedfork/rsrc testbin/._buildDMG
-rwxr-xr-x 1 me me 45607 29 Mar 11:48 bin/buildDMG/..namedfork/rsrc
-rwxr-xr-x 1 me me 45689 30 Apr 22:33 testbin/._buildDMG

Same result extracting files with unzip after using "ditto -k ..." to create a zip instead of a compressed cpio archive.

What accurately restored file forks was using ditto (of course) or opening the compressed zip file in Finder, causing BOMArchiveHelper to process it. However, that restores the entire archive and I was looking for ways to extract individual files.

Opening the compressed cpio archive in Finder generated some error about permissions, which might have been because some of the files were read- or execute-only even tho' I was the owner. No time to figure that out.

Also, the ditto man page recommends using a .cpgz extension for compressed cpio archives. This allows BOMArchiveHelper to process them in a single pass when double-clicked in Finder. Otherwise only the cpio file is uncompressed.

The bottom line is I'm not sure how to extract individual files with resource forks from ditto-created archives with complete integrity.

Whew, that adventure was more than I bargained for. :-)

[ Reply to This | # ]