ftp "mount"

pedz

Registered
I'm trying to do one of those pretend mounts where Mac OS X does ftp under the covers and creates a mount point. It is not working.

I can open Terminal and ftp to the host just fine. It requires an id and password. I've tried various ftp://user@host and ftp//user:password@host syntaxes and none of them work.

If I do ftp://user@host, after a long while ( a minute or so? ), I get a dialog box asking for a password. I give it a password and then another minute or so goes by before it finally fails.

My question is how do I debug this? Is there a way to watch the traffic go back and forth? Something simpler than tcpdump? And is there any way to configure it if I find something I need to change?

Thanks,
pedz
 
To mount an FTP site under MacOS X, all you have to do is to select the Go > Connect to Server... menu item within the Finder. Type the site's URL in the resulting dialog box. The site should appear on the Desktop as a mounted volume. Be reminded that this will grant you read-only (download) access to the site. To mount FTP sites on the Desktop with read/write (download/upload), you need Interarchy. Traditional FTP clients also work like a charm. FTP client Cyberduck is fantastic and free. The advantage of mounting an FTP site on your Desktop is that you can use files on the site without downloading them.
 
The key to your reply is "should". Yes, I know all that. Did you read my original post?

In this particular case for this particular site, it does not. I need to debug it. I'm asking for help on how to debug it. Are there any settings under the covers somewhere that I can access?
 
There probably are _tons_ of settings you could adjust on the FTP server. The client, on OS X' side, however does not have any settings. Either you can access that server via FTP (username and password provided) or not. I'm not a fan of the Finder's (in)ability to mount FTP servers, because it's very limited (can't write to the server, for example). You might be better off just using an FTP application like Fetch.
 
To mount an FTP site under MacOS X, all you have to do is to select the Go > Connect to Server... menu item within the Finder. Type the site's URL in the resulting dialog box. The site should appear on the Desktop as a mounted volume. Be reminded that this will grant you read-only (download) access to the site. To mount FTP sites on the Desktop with read/write (download/upload), you need Interarchy. Traditional FTP clients also work like a charm. FTP client Cyberduck is fantastic and free. The advantage of mounting an FTP site on your Desktop is that you can use files on the site without downloading them.

Fetch or Transmit are two other great options.

I think you might be best served using an ftp client because then you can select 'Passive FTP' which seems to cause major problems if not selected, and non-connectivity.
 
Here's the ftp url you need to input the full ftp string without user and password fields:

ftp://user:password@hostportpath

More on ftp urls here:
http://www.cs.tut.fi/~jkorpela/ftpurl.html

I'm trying to do one of those pretend mounts where Mac OS X does ftp under the covers and creates a mount point. It is not working.

I can open Terminal and ftp to the host just fine. It requires an id and password. I've tried various ftp://user@host and ftp//user:password@host syntaxes and none of them work.

If I do ftp://user@host, after a long while ( a minute or so? ), I get a dialog box asking for a password. I give it a password and then another minute or so goes by before it finally fails.

My question is how do I debug this? Is there a way to watch the traffic go back and forth? Something simpler than tcpdump? And is there any way to configure it if I find something I need to change?

Thanks,
pedz
 
I'm not a fan of the Finder's (in)ability to mount FTP servers, because it's very limited (can't write to the server, for example).

I wonder what Apple's excuse is for not having better FTP functionality built into the Finder when that's exactly what the Go->iDisk command does. Is it just a crass move to maximize .Mac (now called mobileme, I guess) subscriptions?
 
It is in the finder. Hit command + K and access any server you want.

You can access any server you want, but there's no write access--even if you use the user/password ftp string (like what you gave in your previous post) and your directories on that server have write access permissions.

Most annoying.
 
Also, the firewall doesn't affect the operation of Fetch, my usual ftp client.

Wasn't worried about fetch. :) Using Connect to Server is just another way to go.

So, are you used to working on a PC? Your workflow seems to point to that, I work on a pc more these days too. Maybe it's an issue with the server on the other end that won't let you through?
 
So, are you used to working on a PC? Your workflow seems to point to that, I work on a pc more these days too. Maybe it's an issue with the server on the other end that won't let you through?

I'm not going to touch that Mac-vs.-PC bait; no need for sectarian strife (imagine a winking/smiley icon here). Suffice to say that I only use a Mac.

The inability to write to ftp connections via the Mac Finder is consistent on several different servers where I have accounts. It appears to be intentionally designed that way by Apple; the reasoning behind this is difficult to guess.
 
Interesting. So is Apple figuring that WebDAV is the future (i.e. replacement) of FTP? Is that why they don't support writing to FTP servers via the Finder?
I don't know why. I'm not the right person to ask about what Apple's figuring for the future. I was simply clarifying what protocol iDisk uses for data transfer.

I am just as puzzled as you about why FTP support in the Finder is read-only. It's been this way since the beginning of OS X.
 
At the beginning, they clearly wanted to promote WebDAV, and it made some sense. Now, it seems, Apple just doesn't see a point in adding full FTP support. It's not a feature that'd wow the crowds... (Sadly. I'm still missing good/full FTP support in Finder.)
 
The cure to this is FUSE. It should be able to do read/write ftp, ssh, etc etc file systems. I've not used it but I've poked at it a bit. A google search yields some Mac projects to port it.
 
I've not used it so take what I say with a grain of salt. I was / am doing a port of it to AIX but that project has not progressed very far.

FUSE appears as a file system type in the virtual file system table. It ties into the virtual file system level inside the kernel and then sends the requests up to application level processes. It implements a complete set of virtual file system entry points (which is a lot of entry points).

To back up briefly, each of the basic Mac file system types such as "Mac Extended", ZFS, DOS, etc, sit in one slot of the virtual file system table. A mount point in the file system points to one of the entries in the VFS table. For a read on file foo on mount point bar of type cdr, uses the read entry point in the cdr entry in the VFS table.

So, just as you can mix various file systems on a Mac and the finder does not really know or care, FUSE would simply be a new file system type. Mount points using FUSE would work the same as other mount points.

Some functions may be not implemented in the underlying protocol. For example, ftp may not have a chown or chmod facility (I haven't checked). And, even if modern ftp does, the ftp server being used may not implement them. Remember that ftp goes back to prehistoric days.

The finder should not know the difference between sitting on top of a FUSE mounted directory or file and a local file. Some operations, if not implement at some level, would simply fail.

FUSE is not tied to FTP. There are tons of FUSE client implementations for all sorts of odd things. I'm not sure but a plausible example would be mounting a tar file and it would appear as a directory of files and directories.

Its not blindingly fast I gather from reading the mail threads, etc. but so what.

The beauty of fuse is that non-root users can add their own mount points and even their own fuse client implementation safely (its claimed).
 
Back
Top