Subject: Netatalk and NFS

From: Darron Froese <[email-masked]>
Date: Sun, 07 Jan 2001 15:27:13 -0700

Does anyone share folders with Netatalk that are actually NFS mounts from
another machine?

Here's my setup:

Linux 2.2.17 NFS --->  Linux 2.2.16 Netatalk ---> Mac OS Clients

My Netatalk server (running 1.5pre3) only has a 4GB drive (and is only
expandable using SCSI-2 drives that are mucho $$$ in price) while my NFS
server has a 46GB IDE drive. I would like to use that 46GB drive
transparently from the one netatalk server.

I've mounted a few directories on my Netatalk server from the NFS server:

[darron@computer darron]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             242M  146M   83M  64% /
/dev/sda8             1.3G  387M  845M  31% /home
/dev/sda5             145M  7.0k  138M   0% /tmp
/dev/sda7             1.6G  1.3G  230M  85% /usr
/dev/sda4             218M  104M  102M  50% /var
/dev/sda6             290M  136M  139M  50% /web
server:/home/darron/MP3
                       40G  7.1G   31G  19% /home/darron/mp3
server:/home/darron/archives
                       40G  7.1G   31G  19% /home/darron/archives
server:/home/darron/backup
                       40G  7.1G   31G  19% /home/darron/backup

I have no problems working with these files in the NFS mounted directories
when I'm logged in to the shell or remotely via FTP and HTTP.

I cannot copy/write to those NFS mounted directories via Netatalk - I get
errors:

"The item $Item cannot be read because it's in use."
"The item $item cannot be written because it's in use."

I can copy and write to directories that aren't NFS mounted just fine.

Anyone have any ideas for me? Anyone already doing this?

Would it be a workaround to smbmount those directories?
-- 
Darron
[email-masked]

---

From: Matthew Keller <[email-masked]>
Date: Mon, 08 Jan 2001 10:29:06 -0500

Make sure your time on both NFS server and NFS client are the same-
Down to the second. I use the following flags when I mount NFS volumes
for share with Netatalk. You gotta turn off NFS locking because Apple is
lame and is CONSTANTLY writing and reading resource forks while a file
is open (even in the midst of a copy)

nolock,nosuid,noexec,wsize=8192,bg,nodev,rsize=8192,intr

-- 

 Matthew Keller
 WebMaster, Interim Network Manager & 
   Host 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: Tim Carlson <[email-masked]>
Date: Mon, 8 Jan 2001 09:06:25 -0700 (MST)

> nolock,nosuid,noexec,wsize=8192,bg,nodev,rsize=8192,intr

FYI, I have encountered no problems with pre-asun2.1.4-39_test on Solaris
7 and grabbing shares that are NFSed from another Solaris box. Of course
this is all NFSv3 which you probably aren't using on your Linux boxes.

As for the time syncing I would agree that it is important to keep time
current among machines that are NFSing things around. Recent
versions of GNU "make" really complain if the time is different. If you
aren't using ntp or some such utility, you should be :)

Tim

Tim Carlson                                  Voice:    (505) 984-8800x255
Director of Computing: Santa Fe Institute    Fax:      (505) 982-0565
WWW: http://www.santafe.edu/~tim             Email:   [email-masked]

---

From: Matthew Keller <[email-masked]>
Date: Mon, 08 Jan 2001 11:17:09 -0500

> this is all NFSv3 which you probably aren't using on your Linux boxes.

	Yes, NFSv3 is way nice, and v3 support in Linux 2.2 kernel sucks. v3 in
2.4.0 kernel is alledgedly pretty cool, but I haven't played with it
yet... Maybe this afternoon...

> aren't using ntp or some such utility, you should be :)

	*nod* On an hourly CRON task, IMHO.
-- 

 Matthew Keller

---

From: Tim Carlson <[email-masked]>
Date: Mon, 8 Jan 2001 09:36:48 -0700 (MST)

> 	*nod* On an hourly CRON task, IMHO.

Slightly off topic

<preach>

IMHO that is a horrible method
Please please please look at using ntp. It will save you much pain esp if
the machine you are syncing has bad clock skew. Even after you do your
"rdate -s machinename" you are still out of sync.

</preach>

Tim

---

From: Matthew Keller <[email-masked]>
Date: Mon, 08 Jan 2001 12:03:39 -0500

> "rdate -s machinename" you are still out of sync.

	*lol* You're not the first person to get all bunched up about that. The
problem with NTP is that it is a security hole. It's very easy for any
random person to spoof NTP packets and REALLY mess things up. The
precision needed for file-sharing over FTP only has to be down to the
second (~3 seconds if you do the long math) which an hourly rdate will
accomplish just fine, with only a trivial security risk. (and cuts down
on network traffic too).

-- 

 Matthew Keller

---

From: Tim Carlson <[email-masked]>
Date: Mon, 8 Jan 2001 11:37:24 -0700 (MST)

On Mon, 8 Jan 2001, Matthew Keller wrote:

> random person to spoof NTP packets and REALLY mess things up. 

People keep saying this yet I have never heard of a real life example.
Reading through the NTP documentation it seems that in fact it is quite
hard. I mean there such things as keys in an NTP configuration that people
should use.

Besides that.. all of the script kiddies are more interested in buffer
overruns :)

> accomplish just fine, with only a trivial security risk. (and cuts down

I will use more network traffic in sending this one email than NTP will
use all day :-)

Tim

---

From: Matthew Keller <[email-masked]>
Date: Mon, 08 Jan 2001 14:19:33 -0500

> People keep saying this yet I have never heard of a real life example.

	What's your IP network address? ;)

> I will use more network traffic in sending this one email than NTP will

	Depends on your network.

-- 

 Matthew Keller

---

From: Chip Mefford <[email-masked]>
Date: Mon, 08 Jan 2001 16:40:29 -0500

Tim Carlson wrote:

Subscribe to the securityfocus list.