From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <6B81A986-6489-46E0-87C5-A0ABC6B21208@corpus-callosum.com> References: <6B81A986-6489-46E0-87C5-A0ABC6B21208@corpus-callosum.com> From: =?ISO-8859-1?Q?Rub=E9n_Berenguel?= Date: Sun, 9 Mar 2014 19:05:46 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113a5a9e4b51c204f43057ed Subject: Re: [9fans] Accessing Mac OS Extended drives Topicbox-Message-UUID: c6da42fe-ead8-11e9-9d60-3106f5b1d025 --001a113a5a9e4b51c204f43057ed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jeff, thanks: On Sun, Mar 9, 2014 at 6:52 PM, Jeff Sickel wrote= : > Rub=E9n, > > For better, or worse, nothing really serves HFS+ these days. Apple's > transitioning from AFP to SMB2 when sharing files. I can't say I'm > disappointed that AFP is finally going away. > > Until someone writes an HFSX fs device support you won't be able to mount > a drive formatted under OSX. You could mount a FAT device, within reason= . > > I've had trouble getting Plan 9's NFS server to serve up bits that OSX > client can actually use. Someone else's milage may vary. Same goes for > CIFS. > > Now if you're trying to exportfs to a Mac there are several levels of pai= n > you can go through: > > 1) mac9p -- ask fsb for more details (or google mac9p and find his hg re= po > or the github fork) > Hmmm... The use at your own risk doesn't sound really encouraging... I'm wary of kexts, even installing fuse from brew was a little over the edge. If it wasn't because I have used sshfs in the past and found it almost indispensable in most cases, I would have skipped it. > 2) cifs -- read the aquarela man page > Did yesterday, wasn't convinced and thought nfs would be better... > 3) 9pfuse -- I've not tested this with recent fuse versions > The pipe essentially breaks after ~30 seconds with the latest version of osxfuse, unknown reason (no matter how many d's I add to 9import). I can read the remote drive during this time, access and create files. But when it dies, it dies "hard" so I need to remove the tmp/ns.file in Mac OS, eject the fuse volume, etc. Painful, and anyway, not that useful. > 4) nfs -- this shouldn't be painful, but it is > That's the impression I got from the man pages :( > > But I usually find that connecting to my Plan 9 cpu servers through > drawterm or Inferno tends to be the best bridge|least pain (though mac9p > tends to be a really good option). > Drawterm works like a charm (some day I will compile and try the iOS version...), and I can use it with cp without any problems, everything works as expected. But I wanted a solution that was relatively straightforward so that we (me and my SO) could access the drive without needing (relatively) complicated steps. I don't know what I'll do from this point on, since this was a good "reasoned" way to justify an always on device with Plan9... Now I think it will be a device with Raspbian or Plan9 depending on what I want to do... And it will probably mean Raspbian more often than not (so I can use APL.) Ruben > > -jas > > On Mar 9, 2014, at 3:39 AM, Rub=E9n Berenguel wro= te: > > Thanks Steve. In any case, I can't serve HFS+ serving files because P9 > can't access them. But I could serve a FAT device. > > I finally managed to exportfs the drive, I'm not sure if due to a > combination of things in /lib/namespace or the -t flag in listen1 did the > trick, or the combination of the two. I was happy for around 30 seconds, > which is the time 9pfuse (9import) took to issue a "broken pipe" on my > terminal, killing the connection to my remote disk. Pretty fed up of > setting up a remote drive by now. > > > On Sat, Mar 8, 2014 at 7:27 PM, Steve Simon wrote: > >> > I want my >> > Plan9 host to serve a HFS+ drive. >> >> If you want to serve files (rather than a block device) from plan9 to >> a mac then plan9 has an nfs server and, two cifs servers available. >> >> -Steve >> >> > > --001a113a5a9e4b51c204f43057ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jeff, thanks:


On Sun, Mar 9, 2014 at 6:52 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:
Rub=E9n,=  

For better, or worse, nothing really serves HFS+ = these days.  Apple’s transitioning from AFP to SMB2 when sharing= files.  I can’t say I’m disappointed that AFP is finally = going away.

Until someone writes an HFSX fs device support you= won’t be able to mount a drive formatted under OSX.  You could = mount a FAT device, within reason.

I’v= e had trouble getting Plan 9’s NFS server to serve up bits that OSX c= lient can actually use.  Someone else’s milage may vary.  S= ame goes for CIFS.

Now if you’re trying to exportfs to a Mac there a= re several levels of pain you can go through:

&nbs= p;1) mac9p — ask fsb for more details (or google mac9p and find his h= g repo or the github fork)

Hmmm... The use at your own risk doe= sn't sound really encouraging... I'm wary of kexts, even installing= fuse from brew was a little over the edge. If it wasn't because I have= used sshfs in the past and found it almost indispensable in most cases, I = would have skipped it.
 
 2) cifs — read the aquarela man page
<= /blockquote>

Did yesterday, wasn't convinced and thought nfs would be bet= ter...
 
 3) 9pfuse  — I’ve not tested this with recent f= use versions

The pipe essential= ly breaks after ~30 seconds with the latest version of osxfuse, unknown rea= son (no matter how many d's I add to 9import). I can read the remote dr= ive during this time, access and create files. But when it dies, it dies &q= uot;hard" so I need to remove the tmp/ns.file in Mac OS, eject the fus= e volume, etc. Painful, and anyway, not that useful.
 
 4) nfs — this shouldn’t be painful, bu= t it is

That's the impression I got from the m= an pages :(
 

But I usually find that connecting to my Plan 9 cpu ser= vers through drawterm or Inferno tends to be the best bridge|least pain (th= ough mac9p tends to be a really good option).

Drawterm works like a charm (some day I will compile and try= the iOS version...), and I can use it with cp without any problems, everyt= hing works as expected. But I wanted a solution that was relatively straigh= tforward so that we (me and my SO) could access the drive without needing (= relatively) complicated steps.

I don't know what I'll do from this point on, s= ince this was a good "reasoned" way to justify an always on devic= e with Plan9... Now I think it will be a device with Raspbian or Plan9 depe= nding on what I want to do... And it will probably mean Raspbian more often= than not (so I can use APL.)

Ruben
 

-jas
=
On Mar 9, 2014, at 3:39 AM, Rub=E9n Berenguel <ruben@mostlymaths.net> wrote:=

Thanks Steve. In any c= ase, I can't serve HFS+ serving files because P9 can't access them.= But I could serve a FAT device. 

I finally managed to exportfs the drive, I'm not sure if= due to a combination of things in /lib/namespace or the -t flag in listen1= did the trick, or the combination of the two. I was happy for around 30 se= conds, which is the time 9pfuse (9import) took to issue a "broken pipe= " on my terminal, killing the connection to my remote disk. Pretty fed= up of setting up a remote drive by now.


On Sat,= Mar 8, 2014 at 7:27 PM, Steve Simon <steve@quintile.net> w= rote:
> I want my
> Plan9 host to serve a HFS+ drive.

If you want to serve files (rather than  a block device) from pl= an9 to
a mac then plan9 has an nfs server and, two cifs servers available.

-Steve




--001a113a5a9e4b51c204f43057ed--