I've installed sys-fs/fuse, sys-fs/lufis, and sys-fs/lufs successfully. On-demand mounting using lufis and the lufs ftpfs module works perfectly. But autofs.ftpfs doesn't work. The immediate symptom is: # cd /ftp/ftp.kernel.org/pub -bash: cd: /ftp/ftp.kernel.org/pub: No such file or directory In /var/log/messages, I get the following: Jan 27 11:02:38 apollo automount[10163]: >> mount: unknown filesystem type 'lufs' Jan 27 11:02:38 apollo automount[10163]: mount(generic): failed to mount none (type lufs) on /ftp/ftp.kernel.org Jan 27 11:02:38 apollo automount[10163]: failed to mount /ftp/ftp.kernel.org My /etc/autofs/auto.master has the correct configuration (AFAIK): /ftp /etc/autofs/auto.ftpfs --timeout=60 So it looks like auto.ftpfs is trying to mount the filesystem as type lufs, but mount (and the kernel? I don't know exactly how it works) doesn't know about that type. Which, presumably, is because lufs has been phased out in favor of lufis and fuse and is no longer compiled as a kernel module. But that's just a guess. There might be a simple fix to this but I don't know enough about the intricacies of these modules to find it. Reproducible: Always Steps to Reproduce: 1. emerge sys-fs/fuse sys-fs/lufis sys-fs/lufs net-fs/autofs 2. cat "/ftp /etc/autofs/auto.ftpfs --timeout=60" >> /etc/autofs/auto.master 3. /etc/init.d/autofs start 4. cd /ftp/ftp.kernel.org (or any remote ftp host) Actual Results: "No such file or directory message" and entries in /var/log/messages as above. Expected Results: Auto-mounted remote ftp root on /ftp/ftp.kernel.org (perhaps prompting for username and password? I'm not sure how this information gets passed when using auto.ftpfs). To achieve the effect manually, this command does work: $ lufis fs=ftpfs,host=ftp.kernel.org,username=myuser,password=mypass /ftp/ftp.kernel.org/ -s Portage 2.0.51-r13 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-nitro3_20041117_mil2_3com_matroxfb i586) ================================================================= System uname: 2.6.9-nitro3_20041117_mil2_3com_matroxfb i586 AMD-K6tm w/ multimedia extensions Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Nov 8 2004, 22:50:50)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.8.5-r2, 1.6.3, 1.9.3, 1.5, 1.7.9 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r1 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=k6 -mtune=k6 -O2 -pipe -ftracer -fomit-frame-pointer -fweb" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k6 -mtune=k6 -O2 -pipe -ftracer -fomit-frame-pointer -fweb -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://mirrors.tds.net/gentoo ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://csociety-ftp.ecn.purdue.edu/pub/gentoo/ http://gentoo.chem.wisc.edu/gentoo/ http://mirror.datapipe.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d aalib acpi adns aim alsa apm atlas audiofile bash-completion bcmath berkdb bitmap-fonts bonobo cpdflib crypt cscope ctype cups dba dbase dbm dbx dio doc emacs emacs-w3 esd evo exif f77 fam fastcgi fbcon fftw flash flatfile font-server foomaticdb fortran freetds ftp gd gdbm gif gmac gmp gnome gnutls gpm gstreamer gtk gtk2 guile icq imagemagick imap imlib innodb iodbc ipv6 jabber java jikes jpeg junit kerberos lcms libg++ libgda libwww mbox mime ming mmap mmx mng motif mozilla msn mysql mysqli ncurses nocd nptl nptlonly odbc offensive ofx opengl pam pcntl pcre pda pdflib perl php png posix postgres ppds python quicktime readline recode ruby samba sasl shared sharedmem simplexml slang slp snmp soap sockets socks5 spell spl sqlite ssl svg svga sysvipc tcltk tcpd tetex tidy tiff tokenizer truetype truetype-fonts type1-fonts unicode wmf wxwindows x86 xface xine xinerama xml2 xmms xosd xpm xsl zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS
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.
