Thank you, sqweek. The second golden Golden Apple with καλλιστι on
it is totally yours. The first one went to Russ Cox.

So essentially there shouldn't be a problem with mounting on a single
"public" namespace as long as there is one user on the system. mount
restriction in UNIX systems was put in place because multiple users exist
some of whom may be malicious. Virtualization and jailing will relax that
requirement.

Only because the concept is hidden in Plan 9, though I don't know how.
_Someone_ or _something_ has to decide whether to route your packets
through, say, a ppp interface or an eth interface--when both interfaces are
present--and to do that according to configuration. That won't happen on
its own.

I'm sorry, but this needs a comment.

On Aug 20, 2008, at 5:46 PM, Eris Discordia wrote:

The program does so. What happens is the program sets up a 9P server
that runs in the background as a background process. It takes care of
everything. The user never needs to actually say "my cell phone is
interfacing off a proprietary network" because the program will take
care of that. ftpfs, for instance, doesn't ask the user for port
number, ASCII/Binary mode, etc. More elaborate FTP programs do, and I
don't know why.

Suppose I want to have Windows clients be able to connect to their /usr/ share via SMB.
Plan 9 comes with aquarela, but from the man page, and my own testing, it apparently only calls 9fs where is whatever you type after the \, such that in my case:

\\myplan9server\benhu

will properly prompt for authentication, then execute '9fs benhu' which fails, obviously, since 9fs tries to contact the machine 'benhu', which doesn't exist. Is there another way around this, or would I need to modify /rc/bin/9fs to recognize subdirectories of /usr and mount them on /n just to make this work?

Thanks in advance!

-Ben

The trick you want is in /rc/bin/service/startcifs - this may not be exactly
the code you want but it demonstrates the technique you need.

-Steve

Not (currently) a Plan 9 user, but I gotta chime in:

You're right; it isn't. Is that good or bad? What about in an office
environment? Same answer there?

Way, way out of scope. Kinda like a fusion-powered terminal.

That gets me a hair closer. \\myplan9server\local is still empty after using startcfs, though executing

9fs local
ls /n/local

gives me a listing of the filesystem as it should... am I missing something?

Thanks much!!

-Ben

the correct namespace I would guess, you did do the import before you started cifs?

I think you should be able to connect to \\myplan9server\root implying 9fs root,
though this is just your fossil file system, so /dev/ will be fairly empty.

-Steve

What is there to import? I did this from the cpu/auth/fs server console: /rc/bin/service/startcifs

I'd thought it should be \\myplan9server\local
should do a '9fs local' and give me the contents of /

I might end up modifying startcifs or 9fs after all... :)

Thanks!

-Ben

Hmm... I used consolefs to the /srv/fscons to add srv -A test
then as my user I could do \\myplan9server\test and get the root of the drive.
Looks like a namespace issue after all.
However, might this prevent users from all connecting to the system, unless I add a /srv/ entry for every user who might connect...?

Thanks!

-Ben

On Wed, Aug 20, 2008 at 11:46 PM, Eris Discordia
gmail.com> wrote:

Mount restrictions on unix are needed (among other reasons) because of
a broken security model (ie., suid).