| Summary: | autofs.ftpfs (from lufs package) tries to mount ftp filesystems as type 'lufs' but mount doesn't recognize the type | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael S <gentoo.bugzilla> |
| Component: | [OLD] Core system | Assignee: | Stefan Schweizer (RETIRED) <genstef> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
/sbin/mount.captive
/sbin/mount.ftpfs Better /sbin/mount.ftpfs Better /sbin/mount.ftpfs (again) /sbin/mount.ftpfs |
||
|
Description
Michael S
2005-01-27 08:17:35 UTC
Oops. In step 2 to reproduce, I meant "echo", not "cat". But you probably figured that out. Do you know how to create an autofs script? I have looked at the c-source-code but I have no idea how to make that lufis-compatible. Well, I've just figured out how to create an autofs script, but I'm not sure that would solve the problem. Just now I edited util/auto.ftpfs.c to change "fstype=lufs" to "fstype=fuse", which is what I think lufis uses, and recompiled. Now I get a different response: Jan 31 13:09:08 apollo automount[2701]: >> mount: wrong fs type, bad option, bad superblock on none, Jan 31 13:09:08 apollo automount[2701]: >> or too many mounted file systems To create an autofs script (if I understand correctly), I would need to create a file that provides the necessary mount options to automount. But that's what auto.ftpfs does already. (Try '/etc/autofs/auto.ftpfs ftp.example.com' at the shell prompt.) So the problem is that auto.ftpfs is passing the wrong options, and then the question is, what are the correct options to pass to mount in order to mount an ftp filesystem with fuse and lufis? I can't find this documented anywhere. :( Any thoughts? I dont know if that is even possible. Could you please ask there: http://lists.sourceforge.net/lists/listinfo/fuse-devel Or maybe he will even want to create a native ftpfs like he did for sshfs, so that we can safe the "lufis"-step I think it is possible if we add a /usr/bin/mount.ftpfs .. then we could do mount -t ftpfs and place the handling in that file. See /sbin/mount.captive for captive as an example It's definitely possible, using the lufis executable. From the README in the lufis package: ---- Usage, for exampe: ./lufis fs=sshfs,host=kempelen,username=mszeredi /mnt/lufis/ -s Don't forget the '-s' option, without it the filesystem may misbehave! ---- That works fine if you change sshfs to ftpfs and add a password=... option. But although the result is a mounted filesystem of type fuse, calling mount -t fuse -o <options> using the option string above doesn't work, and my C isn't good enough to figure out from lufis.c how it composes the options it then passes to mount. So yes, I'll check on the fuse-devel list and see if he has an answer or wants to create a native ftpfs-fuse module. Incidentally, I don't have /sbin/mount.captive. What package provides that? captive .. what else? :) Oh, right. :-} OK, Miklos says doing what I was hoping to do is not possible. Here's the thread on Sourceforge: http://sourceforge.net/mailarchive/forum.php?thread_id=6466089&forum_id=42692 So as you suggested, Stefan, I'm going to look into writing a ftpfs equivalent to /sbin/mount.captive (as soon as I emerge captive... :) ). In the meantime, it seems like maybe the auto.ftpfs (and auto.sshfs?) executables should be removed from the lufs package. They don't work, and they're never going to work, at least the way the package is currently configured to build (relying on the fuse module rather than compiling a separate lufs module). Thoughts? Or is there another way to get them working that I've missed? Thanks for your help, in any case. Created attachment 50219 [details]
/sbin/mount.captive
I attached you my mount.captive so that you do not have to emerge it ;)
Also I removed the broken autofs stuff from lufs, thanks.
Created attachment 50230 [details]
/sbin/mount.ftpfs
Thanks! But too late, I had already emerged. Never mind, I appreciate the
effort.
For the record I've attached my /sbin/mount.ftpfs which is straight from
Miklos's suggestion on the fuse-devel list. It works as follows:
# mount -t ftpfs ftp.server.com /path/to/mount/point
and you can pass it -o <options> as well, as long as you pass them after the
mount point (it's very basic).
I haven't got it working with autofs yet.
" as you pass them after the mount point (it's very basic)." I dont think this restriction is needed .. maybe we could get rid of it? Also it looks like your script always reads username and password, even when it is a public server with anonymous login. /sbin/mount.ftpfs: #!/bin/bash /usr/bin/lufis fs=ftpfs,host=$1,quiet,$4 $2 -s /sbin/mount.sshfs: #!/bin/bash /usr/bin/lufis fs=sshfs,host=$1,quiet,$4 $2 -s do you like that solution? Created attachment 50551 [details]
Better /sbin/mount.ftpfs
That works ok... still requires strict positioning of its arguments.
I've attached a more extensive version that does some error checking and
parsing of command-line options.
It depends on getopt(1), which is part of the sys-apps/util-linux package, and
I think is part of the system group in all profiles. So we should be able to
count on people having that, right?
Let me know what you think -- probably one of the longer bash scripts I've
written.
Created attachment 50552 [details]
Better /sbin/mount.ftpfs (again)
Oops, the attachment didn't get included before.
for me another order also works .. seems like mount is handling it :) Your script is really an advantage .. looks good for your first one :) The real problem I see in your script is, that I cant do just anonymous mounts, which is the thing, I mostly do with ftpfs. I think we should not ask for email when mounting anonymous, we should not even ask for password when none is given and just assume anonymous. We should implement something like username=ask or password=ask rather then relying on self-made functions in a mount-script, what do you think? Well, it just asks you for your email address, it doesn't require that you give it... :) What do you mean by "implement something like username=ask or password=ask rather then relying on self-made functions in a mount-script"? I'm not following. Other than that, though, there's a bigger problem, which is that when this gets called by 'mount -t ftpfs' some of the options I've been relying on don't get passed to mount.ftpfs, and I can't figure out how to control which options do and don't get passed. So it looks like I'd have to revise it to pass everything in the -o string unless there's another way of doing this. Any ideas? Created attachment 50603 [details]
/sbin/mount.ftpfs
I think in that way it should be ok, no one has to hide usernames ..
What do you think?
there is no urgency about this .. when you have a chance to test it please reopen. |
