Re: autofs for /home: exclude admin users
hallo Darac, Darac Marjal writes: > On 01/04/2024 07:55, Felix Natter wrote: > > hello debian-users, > > I configured autofs for /home: > > * -fstype=nfs,rw,soft,bg,intr SERVER:/share/& > > Just to point out that this is "/share", not "/home". You might have set > user's home directories to be /share/, but you've not mentioned that > explicitly. you interpreted this wrongly: The whole config is for /home (defined in /etc/auto.home and /etc/auto.misc or similar). The * means "any username", and the right hand side is saying "mount SERVER:/share/$1 as /home/$1" using NFS. > But now the login as "admin" does not work any more, since > it tries to mount SERVER:/share/admin -> Is it possible to exclude > a user from automounting? > > Probably the simplest method is to ensure that "admin"'s home directory isn't > below /share. You could keep that under /home, or make a new folder, as you > prefer. Ok, that is an idea: Change /etc/passwd so that "admin" gets the home from /export/admins/admin. The (small) downside is that I potentially need to do this for every admin around (In my "workaround" I can make /etc/auto.home executable and use bash's wildcard matching). > The workaround [1] I use is this: > > admin -fstype=nfs,rw,soft,bg,intr localhost:/export/admin_homes/& > * -fstype=nfs,rw,soft,bg,intr SERVER:/share/& > > where /export/admin_homes/admin is just a normal directory. > > [1] > https://serverfault.com/questions/245121/how-to-prevent-autofs-from-mounting-over-specific-directories > > Is this a valid solution? Will it work on Debian/Ubuntu/... also in the > future? Since I already did it that way: Can somebody please tell me whether my "workaround" is valid? > I use FreeIPA to manage my NFS home directories, and I've set my users there > to have home directories under /home/ipa/. This means that > non-FreeIPA users (i.e. if I need a machine-only user) have their homes under > /home/ which isn't NFS-mounted. Yes, thanks (this is similar to your suggestion above). I would have do it the other way around, i.e. keep the homes in /home, as users' Homes depend on it. Many Thanks and Best Regards, Felix -- Felix Natter debian/rules!
Re: autofs for /home: exclude admin users
On 01/04/2024 07:55, Felix Natter wrote: hello debian-users, I configured autofs for /home: * -fstype=nfs,rw,soft,bg,intr SERVER:/share/& Just to point out that this is "/share", not "/home". You might have set user's home directories to be /share/, but you've not mentioned that explicitly. But now the login as "admin" does not work any more, since it tries to mount SERVER:/share/admin -> Is it possible to exclude a user from automounting? Probably the simplest method is to ensure that "admin"'s home directory isn't below /share. You could keep that under /home, or make a new folder, as you prefer. The workaround [1] I use is this: admin -fstype=nfs,rw,soft,bg,intr localhost:/export/admin_homes/& * -fstype=nfs,rw,soft,bg,intr SERVER:/share/& where /export/admin_homes/admin is just a normal directory. [1] https://serverfault.com/questions/245121/how-to-prevent-autofs-from-mounting-over-specific-directories Is this a valid solution? Will it work on Debian/Ubuntu/... also in the future? Many Thanks and Best Regards, Felix I use FreeIPA to manage my NFS home directories, and I've set my users there to have home directories under /home/ipa/. This means that non-FreeIPA users (i.e. if I need a machine-only user) have their homes under /home/ which isn't NFS-mounted. OpenPGP_signature.asc Description: OpenPGP digital signature
autofs for /home: exclude admin users
hello debian-users, I configured autofs for /home: * -fstype=nfs,rw,soft,bg,intr SERVER:/share/& But now the login as "admin" does not work any more, since it tries to mount SERVER:/share/admin -> Is it possible to exclude a user from automounting? The workaround [1] I use is this: admin -fstype=nfs,rw,soft,bg,intr localhost:/export/admin_homes/& * -fstype=nfs,rw,soft,bg,intr SERVER:/share/& where /export/admin_homes/admin is just a normal directory. [1] https://serverfault.com/questions/245121/how-to-prevent-autofs-from-mounting-over-specific-directories Is this a valid solution? Will it work on Debian/Ubuntu/... also in the future? Many Thanks and Best Regards, Felix -- Felix Natter debian/rules!
Re: autofs config [SOLVED]
Hi. On Tue, 10 Jan 2017 19:32:54 -0500 Harry Putnam wrote: > Reco writes: > > [...] > > >> ls /prj/d0 or ls /prj/dv both fail. However another share on that > >> same setup on the solaris host `gv' and 2x comes up as expected. > > > > You lost me here. If 'd0' and 'dv' are share names, you should use > > auto.net like this: > > This problem is solved with your previous post. Here is how > > All this time my map file said dv --type[...] 2x:/projects/dv >instead of: dv-type[...] [...] > I had two dashes instead of one. > > When copying the part you specified as being verbatim ... I finally > saw my mistake > > I'm really sorry I jerked you around so much. Now that I got the > right formulation I notice that `ls /projects-nfs/dv' mounts so fast > that the ls displays instantly. > > I didn't post the debug data... since it was a fool mistake on my > part. > > You've been very patient. Thank you. You're welcome. Reco
Re: autofs config
Reco writes: [...] >> ls /prj/d0 or ls /prj/dv both fail. However another share on that >> same setup on the solaris host `gv' and 2x comes up as expected. > > You lost me here. If 'd0' and 'dv' are share names, you should use > auto.net like this: This problem is solved with your previous post. Here is how All this time my map file said dv --type[...] 2x:/projects/dv instead of: dv-type[...] [...] I had two dashes instead of one. When copying the part you specified as being verbatim ... I finally saw my mistake I'm really sorry I jerked you around so much. Now that I got the right formulation I notice that `ls /projects-nfs/dv' mounts so fast that the ls displays instantly. I didn't post the debug data... since it was a fool mistake on my part. You've been very patient. Thank you. > > cd /prj//d0 > cd /prj//dv > > If d0 and dv are host names - poke them with 'showmount -e' first, and > use them like this: Sorry for that confusion too. No they are not host names in this usage. They are host names on my lan but on the server that is serving these shares (Solaris host 2x) they are share names. [...] >> So ls /prj/gv after a pause shows /prj/gv/merb/ > > Therefore 'gv' is a host name and 'merb' is a share on that host. > Assuming you're using stock auto.net. > Debug autofs output confirms this: Egad... sorry I wrote it all wrong. I should have said: ls /prj/gv merb `gv' is a share name on host 2x. and merb is a directory under that share. So on host 2x: ls /projects/gv/ merb And on host DEBIAN `ls /prj/gv merb I wrote it wrong and thoroughly confused things. When I meant to show that it some shares were mounted as expected 2 strikes against me... I hope to be more careful in any more posting on this list.
Re: autofs config
Hi. On Tue, 10 Jan 2017 12:50:44 -0500 Harry Putnam wrote: > I finally got around to trying the auto.net file you mentioned in your > first reply in this thread. > > I still cannot read it and understand what it does but I may have some > good news to report. The idea is that auto.net takes top-level directory (/prj in your case) as a place to mount. Then it takes second-level directory as server name and invokes 'showmount -e' on that server. Third-level (and lower) directory should be a share name on that server. So, > Still unable to mount the shares I'm after `d0' and `dv' but, those > fail still with auto.master like: >/prj /etc/auto.net --timeout=90 That part of configuration is correct. > ls /prj/d0 or ls /prj/dv both fail. However another share on that > same setup on the solaris host `gv' and 2x comes up as expected. You lost me here. If 'd0' and 'dv' are share names, you should use auto.net like this: cd /prj//d0 cd /prj//dv If d0 and dv are host names - poke them with 'showmount -e' first, and use them like this: cd /prj/d0/ cd /prj/dv/ > So ls /prj/gv after a pause shows /prj/gv/merb/ Therefore 'gv' is a host name and 'merb' is a share on that host. Assuming you're using stock auto.net. Debug autofs output confirms this: update_offset_entry: parse(sun): updated multi-mount offset /merb -> -fstype=nfs4,soft,intr,nodev,nosuid,async gv:/merb Reco
Re: autofs config
Reco writes: [...] Harry wrote: >> So maybe that has something to do with the problem... Reco replied: > Hardly. The way you're doing on Solaris it you provide NFS shares to > everyone and their dog in read-write mode with sec=sys by NFS versions > ranging from two to four. At least these are defaults starting with > Solaris 10. > > The thing that's broken here is autofs, not NFS implementation. I finally got around to trying the auto.net file you mentioned in your first reply in this thread. I still cannot read it and understand what it does but I may have some good news to report. Still unable to mount the shares I'm after `d0' and `dv' but, those fail still with auto.master like: /prj /etc/auto.net --timeout=90 The good news is other shares in that same SOLARIS:/projects can be mounted as expected (see attached automount -fg output) ls /prj/d0 or ls /prj/dv both fail. However another share on that same setup on the solaris host `gv' and 2x comes up as expected. So ls /prj/gv after a pause shows /prj/gv/merb/ If I cd in there /prj/gv/merb as plain user reader I can: touch file; rm file and etc. However, all those directories exist at SOLARIS-HOST/projects/* All have the same permissions set, all are zfs fs with sharenfs=on >From solaris host: ls -al projects total 17 drwxrwxrwx+ 9 reader nfsu10 Jan 10 12:34 . drwxrwxrwx+ 2 root sys 3 Jan 8 01:48 .$EXTEND drwxr-xr-x 38 root staff 43 Jan 10 11:20 .. drwxrwxrwx+ 8 reader nfsu10 Nov 12 10:11 2x drwxrwxrwx+ 4 reader nfsu 7 Sep 29 2014 adm drwxrwxrwx+ 4 reader nfsu 5 Jan 10 01:57 d0 drwxrwsrwx+ 26 reader nfsu31 Jan 10 00:49 dv drwxrwxrwx+ 18 reader nfsu22 Jan 12 2015 gv drwxrwxrwx+ 2 reader nfsu 3 Feb 9 2015 prj-fossil -rwxrwxrwx+ 1 reader nfsu 1349 Jan 27 2015 srpscr You may notice output about /projects/reader in the attached automounter output but it has been since deleted from SOLARIS:/projects Also notice the odd looking permissions. A result of: /bin/chmod -R A=everyone@:full_set:fd:allow /projects See home sharenfs is set the same all around >From Solaris:/projects/ for ii in 2x d0 dv gv; do zfs get sharenfs rpool/projects/$ii; done NAME PROPERTY VALUE SOURCE rpool/projects/2x sharenfs onlocal NAME PROPERTY VALUE SOURCE rpool/projects/d0 sharenfs onlocal NAME PROPERTY VALUE SOURCE rpool/projects/dv sharenfs onlocal NAME PROPERTY VALUE SOURCE rpool/projects/gv sharenfs onlocal So still having a time seeing why thos specific shares cannot be mounted. Starting automounter version 5.0.8, master map /etc/auto.master using kernel protocol version 5.02 lookup_nss_read_master: reading master file /etc/auto.master parse_init: parse(sun): init gathered global options: (null) spawn_mount: mtab link detected, passing -n to mount spawn_umount: mtab link detected, passing -n to mount lookup_read_master: lookup(file): read entry /prj master_do_mount: mounting /prj automount_path_to_fifo: fifo name /var/run/autofs.fifo-prj lookup_nss_read_map: reading map file /etc/auto.net parse_init: parse(sun): init gathered global options: (null) spawn_mount: mtab link detected, passing -n to mount spawn_umount: mtab link detected, passing -n to mount mounted indirect on /prj with timeout 90, freq 23 seconds st_ready: st_ready(): state = 0 path /prj handle_packet: type = 3 handle_packet_missing_indirect: token 96, name d0, request pid 3369 attempting to mount entry /prj/d0 lookup_mount: lookup(program): looking up d0 >> clnt_create: RPC: Program not registered lookup(program): lookup for d0 failed dev_ioctl_send_fail: token = 96 failed to mount /prj/d0 handle_packet: type = 3 handle_packet_missing_indirect: token 97, name d0, request pid 3369 dev_ioctl_send_fail: token = 97 handle_packet: type = 3 handle_packet_missing_indirect: token 98, name dv, request pid 3378 attempting to mount entry /prj/dv lookup_mount: lookup(program): looking up dv >> clnt_create: RPC: Program not registered lookup(program): lookup for dv failed dev_ioctl_send_fail: token = 98 failed to mount /prj/dv handle_packet: type = 3 handle_packet_missing_indirect: token 99, name dv, request pid 3378 dev_ioctl_send_fail: token = 99 st_expire: state 1 path /prj expire_proc: exp_proc = 140587597362944 path /prj expire_cleanup: got thid 140587597362944 path /prj stat 0 expire_cleanup: sigchld: exp 140587597362944 finished, switching from 2 to 1 st_ready: st_ready(): state = 2 path /prj handle_packet: type = 3 handle_packet_missing_indirect: token 100, name gv, request pid 3390 attempting to mount entry /prj/gv lookup_mount: lookup(program): looking up gv lookup_mount: lookup(program): gv -> -fstype=nfs4,soft,intr,nodev,nosuid,async /merb gv:/merb parse_mount: parse(sun): expanded entry: -fstype=nfs4,soft,intr,nodev,nosuid,async
Re: autofs config
On Tue, 10 Jan 2017 10:18:53 -0500 Harry Putnam wrote: > Reco writes: > > > To workaround #828217 please comment out the line with '-host' in > > /etc/auto.master. > > Just wanted to get back to you right away about this part. Still > looking into the other things you mentioned. > > The `-hosts' line in auto.master has been commented out from the start. > > Must be shipped with autofs that way, as I did not do it. > > So then apparently it is not #828217 at the bottom of this. Or at > least not because of `net -hosts' being in play. Ok, let's simplify things then. # /etc/auto.master (verbatim): /projects-nfs /etc/auto.prj-nfs --timeout=180 # /etc/auto.prj-nfs (again, verbatim, and it's one line): dv -fstype=nfs4,rw,soft,intr,proto=tcp,sec=sys 2x:/projects/dv Please note that it's tabulation everywhere, not spaces. And please post full debug output of autofs somewhere. Reco
Re: autofs config
Reco writes: > To workaround #828217 please comment out the line with '-host' in > /etc/auto.master. Just wanted to get back to you right away about this part. Still looking into the other things you mentioned. The `-hosts' line in auto.master has been commented out from the start. Must be shipped with autofs that way, as I did not do it. So then apparently it is not #828217 at the bottom of this. Or at least not because of `net -hosts' being in play.
Re: autofs config
Hi. On Mon, Jan 09, 2017 at 06:48:43PM -0500, Harry Putnam wrote: > Reco Wrote: > > Which brings me to this: > > > > 1) What security option are you using (i.e. none, sys, krb5, etc)? > > If unsure, please mount a share by hand and obtain mount options > > from /proc/mounts. > > It appears to be sys (sec=sys) > > 192.168.1.42:/projects/dv /projects/dv nfs4 rw,relatime,vers=4.0,\ > rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,\ > timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.29,local_lock=none,\ > ^^^ > addr=192.168.1.42 0 0 Ok, that simplifies things somewhat. So it's tcp-over-ipv4 type of NFS4 without any security worth mentioning. > > 3) Stop autofs, start it like this: > > > > /usr/sbin/automount -fd > > > > Mount a filesystem. Watch the debug output. Terminate it with Ctrl+C. > > (below I marked with *** what might be a clue) You missed it by two lines ☺: > get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 6 version 0x30 > get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 17 version > 0x30 > > *** mount(nfs): no hosts available To workaround #828217 please comment out the line with '-host' in /etc/auto.master. > As I mentioned in the OP: > The host involved is a solaris x86 host. The file systems set for > nfs availability are not put into an /etc/exports type setup. That's what they want you to beleive. Please check out /etc/dfs/sharetab on NFS server. > The way it is done on solaris with the zfs file system... is during > the creation of a file system with `zfs create' One of the ways of doing it, certainly not the most easiest one. share(1M) is decade older at least and thousand times easier to use. > So maybe that has something to do with the problem... Hardly. The way you're doing on Solaris it you provide NFS shares to everyone and their dog in read-write mode with sec=sys by NFS versions ranging from two to four. At least these are defaults starting with Solaris 10. The thing that's broken here is autofs, not NFS implementation. Reco
Re: autofs config
Reco writes:
[...]
> Won't it be fun otherwise?
>
> The good thing is - autofs is working as intended.
> The bad thing is - mount is failing.
,
| NOTE: I've rearranged your post to put the next question and answer at
| the bottom of this reply
`
[...] missing q and a
>> One question... am I supposed to create the directories
>> /projects/dv /projects/d0 ?
>>
>> It appears from the instructions I've seen that .. no I am not to
>> create those dir... just /projects/. however, I did try it both ways
>> and can report that nothing gets mounted in either test.
>
> No, you definitely do not. Either autofs creates a directory for you, or
> you're unable to mount it. Top-level directory *must* be created, but
> you did it.
Well at least I got that part right.
[...]
>>/projects /etc/auto.net --timeout=180 (Note: It now says
>> `auto.net')
>>+dir:/etc/auto.master.d
>>+auto.master
>
Reco wrote
> Should be something like this:
>
> /projects program:/etc/auto.net --timeout=180
Ok, commented out the 2 lines that were uncommented by default
[...]
> A small nit. Do not use 'hard' mount option unless you absolutely need
> it. It is painful, and it's by design. It has nothing to do with your
> current problem, though. What you probably need is:
>
> -fstype=nfs4,soft,intr,nodev,nosuid,async
All right, good to know.
--- --- ---=--- --- ---
And now the question answer I moved:
Reco Wrote:
> Which brings me to this:
>
> 1) What security option are you using (i.e. none, sys, krb5, etc)?
> If unsure, please mount a share by hand and obtain mount options
> from /proc/mounts.
It appears to be sys (sec=sys)
192.168.1.42:/projects/dv /projects/dv nfs4 rw,relatime,vers=4.0,\
rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,\
timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.29,local_lock=none,\
^^^
addr=192.168.1.42 0 0
[...]
> 3) Stop autofs, start it like this:
>
> /usr/sbin/automount -fd
>
> Mount a filesystem. Watch the debug output. Terminate it with Ctrl+C.
(below I marked with *** what might be a clue)
--- --- ---=--- --- ---
parse_init: parse(sun): init gathered global options: (null)
spawn_mount: mtab link detected, passing -n to mount
spawn_umount: mtab link detected, passing -n to mount
mounted indirect on /test with timeout 90, freq 23 seconds
st_ready: st_ready(): state = 0 path /test
handle_packet: type = 3
handle_packet_missing_indirect: token 47, name dv, request pid 11696
attempting to mount entry /test/dv
lookup_mount: lookup(file): looking up dv
lookup_mount: lookup(file): dv -> --fstype=nfs4,rw,soft,intr
191.168.1.42:/test
parse_mount: parse(sun): expanded entry: --fstype=nfs4,rw,soft,intr
191.168.1.42:/test
parse_mount: parse(sun): gathered options: -fstype=nfs4,rw,soft,intr
parse_mount: parse(sun): dequote("191.168.1.42:/test") -> 191.168.1.42:/test
parse_mount: parse(sun): core of entry: options=-fstype=nfs4,rw,soft,intr,
loc=191.168.1.42:/test
sun_mount: parse(sun): mounting root /test, mountpoint dv, what
191.168.1.42:/test, fstype nfs, options -fstype=nfs4,rw,soft,intr
mount_mount: mount(nfs): root=/test name=dv what=191.168.1.42:/test,
fstype=nfs, options=-fstype=nfs4,rw,soft,intr
mount_mount: mount(nfs): nfs options="-fstype=nfs4,rw,soft,intr", nobind=0,
nosymlink=0, ro=0
get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 6 version 0x30
get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 17 version 0x30
*** mount(nfs): no hosts available
dev_ioctl_send_fail: token = 47
failed to mount /test/dv
handle_packet: type = 3
handle_packet_missing_indirect: token 48, name dv, request pid 11696
dev_ioctl_send_fail: token = 48
st_expire: state 1 path /test
expire_proc: exp_proc = 140662262839040 path /test
expire_cleanup: got thid 140662262839040 path /test stat 0
expire_cleanup: sigchld: exp 140662262839040 finished, switching from 2 to 1
st_ready: st_ready(): state = 2 path /test
st_expire: state 1 path /test
expire_proc: exp_proc = 140662262839040 path /test
expire_cleanup: got thid 140662262839040 path /test stat 0
expire_cleanup: sigchld: exp 140662262839040 finished, switching from 2 to 1
st_ready: st_ready(): state = 2 path /test
[...]
--- --- ---=--- --- ---
As I mentioned in the OP:
The host involved is a solaris x86 host. The file systems set for
nfs availability are not put into an /etc/exports type setup.
The way it is done on solaris with the zfs file system... is during
the creation of a file system with `zfs create'
One usees an option (-o) that looks like:
zfs create -o sharenfs=on -o sharesmb=on somezpool/some/path
So in the case
Re: autofs config
Hi. On Mon, 09 Jan 2017 08:14:51 -0500 Harry Putnam wrote: > Reco wrote: > > Note that it be simplified to: > > > > * --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/& > > I created /etc/auto.nfs and tried that forumulation. Restarted > autofs. Nothing gets mounted under (now simplified to /projects in > auto.master) /projects when I do ls /projects/d0 or /projects/dv > > There is a bit of a pause with `ls /projects/dv (or d0) but then I > get: > ls: cannot access /projects/dv: No such file or directory Won't it be fun otherwise? The good thing is - autofs is working as intended. The bad thing is - mount is failing. Which brings me to this: 1) What security option are you using (i.e. none, sys, krb5, etc)? If unsure, please mount a share by hand and obtain mount options from /proc/mounts. 2) If you're using kerberos, can autofs access krb5.conf and krb5.keytab? 3) Stop autofs, start it like this: /usr/sbin/automount -fd Mount a filesystem. Watch the debug output. Terminate it with Ctrl+C. > One question... am I supposed to create the directories > /projects/dv /projects/d0 ? > > It appears from the instructions I've seen that .. no I am not to > create those dir... just /projects/. however, I did try it both ways > and can report that nothing gets mounted in either test. No, you definitely do not. Either autofs creates a directory for you, or you're unable to mount it. Top-level directory *must* be created, but you did it. > > Also please note that they give you /etc/auto.net just for your case > > (i.e. mounting nfs). > > Not sure what you mean by `give you'. Do you mean to use as is? > I tried: >root # grep -v '^#\|^$' /etc/auto.master >/projects /etc/auto.net --timeout=180 (Note: It now says `auto.net') >+dir:/etc/auto.master.d >+auto.master Should be something like this: /projects program:/etc/auto.net --timeout=180 > Made sure auto.net is chmod 755 Yep, it's importanet. > Changed (in auto.net) > opts="-fstype=nfs,hard,intr,nodev,nosuid" > #opts="-fstype=nfs4,hard,intr,nodev,nosuid,async" > To: > #opts="-fstype=nfs,hard,intr,nodev,nosuid" > opts="-fstype=nfs4,hard,intr,nodev,nosuid,async" A small nit. Do not use 'hard' mount option unless you absolutely need it. It is painful, and it's by design. It has nothing to do with your current problem, though. What you probably need is: -fstype=nfs4,soft,intr,nodev,nosuid,async Reco
Re: autofs config
Reco writes: [...] > And it gone haywire from here. Hehe... thats a good description... > Autofs has a concept of master map ( auto.master(5) ) which can contain > lines referring to either direct or indirect maps ( autofs(5) ). > > /etc/auto.master.d is intended for extending master map, and the files > inside it should contain master map entries, not indirect ones like you > did below. Thanks... and I got that all squared away. [...] Harry wrote >> created /etc/auto.master.d/prj-nfs.autofs like so (as suggested in >> auto.master): >> >> d0 --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/d0 >> dv --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/dv > Reco wrote: > Note that it be simplified to: > > * --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/& I created /etc/auto.nfs and tried that forumulation. Restarted autofs. Nothing gets mounted under (now simplified to /projects in auto.master) /projects when I do ls /projects/d0 or /projects/dv There is a bit of a pause with `ls /projects/dv (or d0) but then I get: ls: cannot access /projects/dv: No such file or directory To clarify my above comments: root # grep -v '^#\|^$' /etc/auto.master /projects /etc/auto.nfs --timeout=180 +dir:/etc/auto.master.d +auto.master root # grep -v '^#\|^$' /etc/auto.nfs *--fstype=nfs4,rw,soft,intr191.168.1.42:/projects/& I also tried this: root # grep -v '^#\|^$' /etc/auto.nfs d0 --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/d0 dv --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/dv A `ls /projects/dv' pauses maybe 10 seconds and returns: ls: cannot access /projects/dv: No such file or directory One question... am I supposed to create the directories /projects/dv /projects/d0 ? It appears from the instructions I've seen that .. no I am not to create those dir... just /projects/. however, I did try it both ways and can report that nothing gets mounted in either test. > Also please note that they give you /etc/auto.net just for your case > (i.e. mounting nfs). Not sure what you mean by `give you'. Do you mean to use as is? I tried: root # grep -v '^#\|^$' /etc/auto.master /projects /etc/auto.net --timeout=180 (Note: It now says `auto.net') +dir:/etc/auto.master.d +auto.master Made sure auto.net is chmod 755 Changed (in auto.net) opts="-fstype=nfs,hard,intr,nodev,nosuid" #opts="-fstype=nfs4,hard,intr,nodev,nosuid,async" To: #opts="-fstype=nfs,hard,intr,nodev,nosuid" opts="-fstype=nfs4,hard,intr,nodev,nosuid,async" Restarted autofs Again, nothing is mounted under /projects/ A `ls /projects/dv (or d0)' returns immediately with output: ls: cannot access /projects/dv: No such file or directory And once again .. to test nfs: mount -t nfs 192.168.1.42:/projects/dv /nfs/dv ls /nfs/dv (Yup... lots of files under here) I'm not able to see what I am doing wrong...
Re: autofs config
Reco wrote: > [1] http://blog.tomecek.net/post/automount-with-systemd/ Note: this only works with static mounts. If you want to use any kind of automatic mapping you can't do this with systemd. Grüße, S° -- Sigmentation fault. Core dumped.
Re: autofs config
Hi. On Sun, 08 Jan 2017 13:37:32 -0500 Harry Putnam wrote: > I've edited /etc/auto.master by adding this line: > > /projects-nfs /etc/auto.master.d/prj-nfs.autofs --timeout=180 And it gone haywire from here. Autofs has a concept of master map ( auto.master(5) ) which can contain lines referring to either direct or indirect maps ( autofs(5) ). /etc/auto.master.d is intended for extending master map, and the files inside it should contain master map entries, not indirect ones like you did below. > Created the directory `mkdir /etc/auto.master.d' > > created /etc/auto.master.d/prj-nfs.autofs like so (as suggested in > auto.master): > > d0 --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/d0 > dv --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/dv Note that it be simplified to: * --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/& Also please note that they give you /etc/auto.net just for your case (i.e. mounting nfs). > *** Jan 08 13:40:45 d0 automount[3676]: syntax error in map near > [ d0 --fstype=nfs4,rw,soft,intr191.168.1.42: ] > *** Jan 08 13:40:45 d0 automount[3676]: syntax error in map near > [ projects ] So, what you need to do instead is: # /etc/auto.master /projects-nfs /etc/auto.nfs --timeout=180 # /etc/auto.nfs d0 --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/d0 dv --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/dv And since you're using Debian stable you might consider ditch autofs altogether as well and use systemd automounting as described in [1]. Reco [1] http://blog.tomecek.net/post/automount-with-systemd/
autofs config
, | NOTE: A similar post was accidently posted to gentoo list but was | intended to be posted here ` Setup: Running Debian jessie-stable I've never used autofs and am trying to get it setup. Following the debian wiki and an Ubuntu howto. Also this site: http://www.linuxtechi.com/automount-nfs-share-in-linux-using-autofs/ I've installed the pkg: aptitude search ^autofs|grep ^i i autofs - kernel-based automounter for Linux created mount point: mkdir /projects-nfs I've edited /etc/auto.master by adding this line: /projects-nfs /etc/auto.master.d/prj-nfs.autofs --timeout=180 Created the directory `mkdir /etc/auto.master.d' created /etc/auto.master.d/prj-nfs.autofs like so (as suggested in auto.master): d0 --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/d0 dv --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/dv Those directories on that host are available. They reside on an solaris (x86) host and set to be available to nfs. They can be mounted manually: mount -t nfs 2x:/projects/dv /nfs/dv Checking /nfs/dv... I find it is mounted. So umounting /nfs/dv And starting autofs with: /etc/init.d/autofs start However when I chk status I get [asterisks added for clarity]: /etc/init.d/autofs status ● autofs.service - LSB: Automounts filesystems on demand Loaded: loaded (/etc/init.d/autofs) Active: active (running) since Sun 2017-01-08 13:40:45 EST; 4s ago Process: 3638 ExecStop=/etc/init.d/autofs stop (code=exited, status=0/SUCCESS) Process: 3671 ExecStart=/etc/init.d/autofs start (code=exited, status=0/SUCCESS) CGroup: /system.slice/autofs.service └─3676 /usr/sbin/automount --pid-file /var/run/autofs.pid Jan 08 13:40:45 d0 systemd[1]: Starting LSB: Automounts filesystems on demand... *** Jan 08 13:40:45 d0 automount[3676]: syntax error in map near [ d0 --fstype=nfs4,rw,soft,intr191.168.1.42: ] *** Jan 08 13:40:45 d0 automount[3676]: syntax error in map near [ projects ] Jan 08 13:40:45 d0 autofs[3671]: Starting automount Jan 08 13:40:45 d0 systemd[1]: Started LSB: Automounts filesystems on demand. No way to tell what the syntax error is. I thought it might be spaces instead of tabs so when back and made sure the whitspaces are tabs. The above sited URL shows the entries for map file are to include: And gives the example: db_backup -fstype=nfs,rw,soft,intr 192.168.1.21:/db_backup I'm not seeing what the `syntax error' is in my file.
autofs does not show all iso content.
Hello. I've setup autofs in Debian 7 to automount iso's when it is accessed via samba. At start it was working fine. I've setup --timeout=5. But as number of iso's grew, autofs started just to create the folders for the corresponding iso's while no content was in them. Some folders have content some don't. I have around 200 iso's in config file. Is there any limit for autofs? Thank you.
Re: zfs, autofs dependencies
Quoting Mimiko (vbv...@gmail.com): > On 03.04.2015 23:21, David Wright wrote: > >I'm as yet unconvinced. I can't see in your original posting where > >you've told ZFS how to manage mounting your volumes. > > > In my original post I've wrote: > > zfs create -V 4T zfspool/backup > zfs create -V 1T zfspool/network > zfs create -V 1T zfspool/op > > mount /dev/zvol/zfspool/backup /backup > mount /dev/zvol/zfspool/network /backup/network > mount /dev/zvol/zfspool/op /backup/op > > Lats three commands can be put in /etc/fstab You can't put commands in /etc/fstab; it's not executable. And there's not much context for those reposted lines... I see you originally did # zpool create -f -m none -o ashift=12 zfspool raidz2 disk1 What does that -m none mean? So you have a pool; then 3 zfs create commands make 3 filesystems? Then, with a directory in your / called /backup, # mount /dev/zvol/zfspool/backup /backup mounted the first created filesystem there. Did you then have to mkdir the mountpoints /backup/network and /backup/op for the following two commands to work? # mount /dev/zvol/zfspool/network /backup/network # mount /dev/zvol/zfspool/op /backup/op Having got everything to mount ok, you then rebooted? Is that right? Sorry to single-step through this, but that's the only way for me to know what you actually did. Cheers, David. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150405053549.ga21...@alum.home
Re: zfs, autofs dependencies
On 03.04.2015 23:21, David Wright wrote: Those scripts have logging lines. Have you read their output? Yes, there are logging, But there is no any suspection lines in that log files. Only error is given when it's trying to mount devices so there are: /backup/network - error mounting /backup/op - error mounting /backup - success Despite that in /etc/fstab the /backup mount is specified first, it is mounting third at order. Its strange. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/551fb230.9030...@gmail.com
Re: zfs, autofs dependencies
On 03.04.2015 23:21, David Wright wrote: I'm as yet unconvinced. I can't see in your original posting where you've told ZFS how to manage mounting your volumes. In my original post I've wrote: zfs create -V 4T zfspool/backup zfs create -V 1T zfspool/network zfs create -V 1T zfspool/op mount /dev/zvol/zfspool/backup /backup mount /dev/zvol/zfspool/network /backup/network mount /dev/zvol/zfspool/op /backup/op Lats three commands can be put in /etc/fstab -- Mimiko desu. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/551fb24d.6080...@gmail.com
Re: zfs, autofs dependencies
Quoting Mimiko (vbv...@gmail.com): > On 01.04.2015 17:55, Reco wrote: > > No, the problem is related to the Debian indeed. As ZFS is used as an > > LVM here, so you might as well replace those fancy/dev/zvol/* with > > something conventional, and the problem will still remain. I'm as yet unconvinced. I can't see in your original posting where you've told ZFS how to manage mounting your volumes. BTW I know nothing about zfs. I feel rather like The Ruler of the Universe/man in a shack (HHG), except I'm asking the questions. [...] > As it can be seen, mount of devices are done in the order which they > are described in /etc/fstab. Maybe the next mount command is started > before previous mount command finished and fully mounted /backup? Those scripts have logging lines. Have you read their output? Cheers, David. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150403202135.ga13...@alum.home
Re: zfs, autofs dependencies
On 01.04.2015 17:55, Reco wrote:
> No, the problem is related to the Debian indeed. As ZFS is used as an
> LVM here, so you might as well replace those fancy/dev/zvol/* with
> something conventional, and the problem will still remain.
>
> Consider the following /etc/fstab.
>
> /dev/sda1 /backup ext4 noauto,nofail,user_xattr 0 2
> /dev/sda2 /backup/network ext4 noauto,nofail,user_xattr 0 2
> /dev/sda3 /backup/op ext4 noauto,nofail,user_xattr 0 2
>
> How do you can use /etc/fstab to specify a mount order? Without
> resorting to the shell scripts, of course.
You are right. ZFS here acts only as an LVM to create those devices. But
zfs-mount reads the content of /etc/fstab and if find's any device
within /dev/zvol/ it does for it a simple mount command.
The zfs-mount contains this script to mount:
read_fstab() {
for fs in "${!FSTAB[@]}" ; do unset FSTAB["$fs"] ; done
while read -r fs mntpnt fstype opts blah ; do
fs=`printf '%b\n' "$fs"`
FSTAB["$fs"]=$mntpnt
done < <(grep -E "$1" /etc/fstab)
}
do_mount()
{
if [ -n "$POOL_IMPORTED" ]; then
[ "$VERBOSE_MOUNT" == 'yes' ] && verbose=v
[ "$DO_OVERLAY_MOUNTS" == 'yes' ] && overlay=O
$log_begin_msg "Mounting ZFS filesystems not yet mounted"
$ZFS mount -a$verbose$overlay $MOUNT_EXTRA_OPTIONS
RET=$?
if [ $RET != 0 ] ; then
$log_end_msg $RET
exit $RET
fi
$log_end_msg 0
read_mtab "^/dev/(zd|zvol)"
read_fstab "^/dev/(zd|zvol)"
$log_begin_msg "Mounting volumes registered in fstab: "
for volume in "${!FSTAB[@]}" ; do
if in_mtab "$volume" ; then continue ; fi
$log_progress_msg "$volume "
mount "$volume"
done
$log_end_msg 0
fi
}
start()
{
checksystem && {
case "$ZFS_MOUNT" in
([Oo][Ff][Ff]|[Nn][Oo]|'')
exit 3
;;
esac
do_import
do_mount
do_mount
touch "$LOCKDIR/$servicename"
}
}
As it can be seen, mount of devices are done in the order which they are
described in /etc/fstab. Maybe the next mount command is started before
previous mount command finished and fully mounted /backup?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/551e3f4c.2050...@gmail.com
Re: zfs, autofs dependencies
Hi. On Wed, 1 Apr 2015 10:33:29 -0400 Dan Ritter wrote: > On Wed, Apr 01, 2015 at 02:15:32PM +0300, Mimiko wrote: > > The question is, is there are method better to overcome this > > problem? How to specify mount order? How to enable zfs import early? > I suspect you will need to talk to the zfsonlinux mailing list. > > http://list.zfsonlinux.org/mailman/listinfo/zfs-discuss No, the problem is related to the Debian indeed. As ZFS is used as an LVM here, so you might as well replace those fancy /dev/zvol/* with something conventional, and the problem will still remain. Consider the following /etc/fstab. /dev/sda1 /backup ext4 noauto,nofail,user_xattr 0 2 /dev/sda2 /backup/network ext4 noauto,nofail,user_xattr 0 2 /dev/sda3 /backup/op ext4 noauto,nofail,user_xattr 0 2 How do you can use /etc/fstab to specify a mount order? Without resorting to the shell scripts, of course. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150401175539.343f9e126e5fcfbc773e2...@gmail.com
Re: zfs, autofs dependencies
On Wed, Apr 01, 2015 at 02:15:32PM +0300, Mimiko wrote: > Hello. > > I've setup a file server on Debian Wheezy x86_64. I've used 2 ssd > for system folders which are partitioned and used in software raid > with mdadm. It's working ok. Also there are a bunch of disks which > are combined in a big disk raid-z2 with zfs: > zpool create -f -m none -o ashift=12 zfspool raidz2 disk1 > > On this poll I've created three volumes: > zfs create -V 4T zfspool/backup > zfs create -V 1T zfspool/network > zfs create -V 1T zfspool/op > > mount /dev/zvol/zfspool/backup /backup > mount /dev/zvol/zfspool/network /backup/network > mount /dev/zvol/zfspool/op /backup/op > > As you can see, network and op a mount into /backup folder. > > No, the problem is where to describe mount parameters so it will > follow the order? I've used in /etc/fstab: > > /dev/zvol/zfspool/backup /backup ext4 > defaults,noauto,nofail,user_xattr,acl,barrier=1 0 2 > /dev/zvol/zfspool/network /backup/network ext4 > defaults,noauto,nofail,user_xattr,acl,barrier=1 0 2 > /dev/zvol/zfspool/op /backup/op ext4 > defaults,noauto,nofail,user_xattr,acl,barrier=1 0 2 > > I've put noauto and nofail parameters so on boot system will not > stop with error, because at boot zfs volumes are not ready and > imported yet. > > Although, that I've used this in fstab, /backup/network and > /backup/op are not mounted because they are mounted by zfs-mount in > incorrect order, before /backup is mounted. So in > /etc/init.d/zfs-mount script I've found do_mount() command and > duplicated it. First time do_mount() mounts only /backup, second > time do_mount() can mount other disks. > > The question is, is there are method better to overcome this > problem? How to specify mount order? How to enable zfs import early? > > Second problem arises for autofs. I've setup it, so in /backup are > some iso files. But when autofs starts it does not find /backup, > because it is not mounted yet. So the mounted by autofs folders are > empty. I need to restart autofs for files to appear. > > How to specify that autofs should start after zfs mounted those partition? I suspect you will need to talk to the zfsonlinux mailing list. http://list.zfsonlinux.org/mailman/listinfo/zfs-discuss -dsr- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150401143329.gk26...@randomstring.org
zfs, autofs dependencies
Hello. I've setup a file server on Debian Wheezy x86_64. I've used 2 ssd for system folders which are partitioned and used in software raid with mdadm. It's working ok. Also there are a bunch of disks which are combined in a big disk raid-z2 with zfs: zpool create -f -m none -o ashift=12 zfspool raidz2 disk1 On this poll I've created three volumes: zfs create -V 4T zfspool/backup zfs create -V 1T zfspool/network zfs create -V 1T zfspool/op mount /dev/zvol/zfspool/backup /backup mount /dev/zvol/zfspool/network /backup/network mount /dev/zvol/zfspool/op /backup/op As you can see, network and op a mount into /backup folder. No, the problem is where to describe mount parameters so it will follow the order? I've used in /etc/fstab: /dev/zvol/zfspool/backup /backup ext4 defaults,noauto,nofail,user_xattr,acl,barrier=1 0 2 /dev/zvol/zfspool/network /backup/network ext4 defaults,noauto,nofail,user_xattr,acl,barrier=1 0 2 /dev/zvol/zfspool/op /backup/op ext4 defaults,noauto,nofail,user_xattr,acl,barrier=1 0 2 I've put noauto and nofail parameters so on boot system will not stop with error, because at boot zfs volumes are not ready and imported yet. Although, that I've used this in fstab, /backup/network and /backup/op are not mounted because they are mounted by zfs-mount in incorrect order, before /backup is mounted. So in /etc/init.d/zfs-mount script I've found do_mount() command and duplicated it. First time do_mount() mounts only /backup, second time do_mount() can mount other disks. The question is, is there are method better to overcome this problem? How to specify mount order? How to enable zfs import early? Second problem arises for autofs. I've setup it, so in /backup are some iso files. But when autofs starts it does not find /backup, because it is not mounted yet. So the mounted by autofs folders are empty. I need to restart autofs for files to appear. How to specify that autofs should start after zfs mounted those partition? Thank you. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/551bd354.3050...@gmail.com
Re: Anyone having troubles with autofs and NTFS formatted drives on Jessie/sid ?
Hi, Thank you very much for your help. Replacing ikki-fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/ikki with ikki-fstype=fuse,gid=46,dmask=002,fmask=113 :ntfs-3g#/dev/ikki solved the problem. ntfs-3g was already installed on my system. Regards. Thierry On Sun, 16 Nov 2014 16:18:36 +0300 Reco wrote: > Hi. > > On Sun, 16 Nov 2014 12:42:31 +0100 > Thierry Rascle wrote: > > > The automounting used to work for all of the entries, but now does not > > for the three entries with "-fstype=ntfs". > > Install ntfs-3g, replace > > -fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/ikki jacala > > with > > -fstype=fuse,gid=46,dmask=002,fmask=113 :ntfs-3g#/dev/ikki jacala > > > You're using in-kernel NTFS implementation which was feature-incomplete > 10 years ago and hasn't developed ever since. > > Reco > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116151422.645eafe4@akela.localdomain
Re: Anyone having troubles with autofs and NTFS formatted drives on Jessie/sid ?
Hi. On Sun, 16 Nov 2014 12:42:31 +0100 Thierry Rascle wrote: > The automounting used to work for all of the entries, but now does not > for the three entries with "-fstype=ntfs". Install ntfs-3g, replace -fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/ikki jacala with -fstype=fuse,gid=46,dmask=002,fmask=113 :ntfs-3g#/dev/ikki jacala You're using in-kernel NTFS implementation which was feature-incomplete 10 years ago and hasn't developed ever since. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116161836.61724982c073ecf589f84...@gmail.com
Anyone having troubles with autofs and NTFS formatted drives on Jessie/sid ?
Hi list, I'm using sid, with wmii as my only window manager and desktop environment. I'm using autofs for automounting my external devices: - CD/DVD drives, - USB sticks formatted as FAT or NTFS, - external hard disk drives formatted has EXT4 or NTFS. or NTFS), CD-ROM drives, external hard disk drives). I dist-upgrade my system very regularly. The automounting used to work perfectly for all my external devices, but since a few weeks (or perhaps a few months), it does not work any more with my NTFS formatted devices. I have to manually mount them instead. Does any one have the same issue ? I can't find any post or bug report about that. I can't tell which package upgrade caused the issue. I believe it is not an upgrade of the autofs package that caused the issue because the autofs package has not been upgraded since March 2014. I have not changed my autofs configuration files recently, so I don't believe they're the cause of the issue. My /etc/auto.master file contains one line: /var/autofs/removable /etc/auto.removable --timeout=2,sync,nodev,nosuid The /etc/auto.removable has the following entries: chikai -fstype=iso9660,ro,sync,nodev,nosuid:/dev/chikai chil-fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/chil eos_digital -fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/eos_digital nikon_d200 -fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/nikon_d200 fao -fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/fao ikki -fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/ikki jacala -fstype=iso9660,ro,sync,nodev,nosuid:/dev/jacala buldeo -fstype=iso9660,ro,sync,nodev,nosuid:/dev/buldeo kaa -fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/kaa mao -fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/mao nag -fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/nag medianavmp3 -fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/medianavmp3 akela2_root -fstype=ext4:/dev/akela2_root akela2_home -fstype=ext4:/dev/akela2_home akela2_tmp -fstype=ext4:/dev/akela2_tmp akela2_usr -fstype=ext4:/dev/akela2_usr akela2_var -fstype=ext4:/dev/akela2_var The automounting used to work for all of the entries, but now does not for the three entries with "-fstype=ntfs". Note that the associated devices in /dev are still created properly when the devices are plugged in, so I don't suspect a udev related issue. Thierry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116124231.219ca73e@akela.localdomain
Squeeze/Wheezy: autofs-ldap -> syntax error in map near [ /nethome/files/disc01 ]
hi, I'm trying to get autofs with LDAP working. We have two file servers (old/new) and several LDAP entries, like described in: /usr/share/doc/autofs-ldap/examples/ldap-automount-rfc2307-bis-auto.direct: === # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # dn: automountMapName=auto_direct,ou=services,ou=RBG,dc=foo objectClass: automountMap objectClass: top automountMapName: auto_direct dn: automountKey=/nethome/fire01/disc01,automountMapName=auto_direct,ou=services,ou=RBG,dc=foo automountKey: /nethome/fire01/disc01 objectClass: automount objectClass: top automountInformation: fire01:/disc01 [...] dn: automountKey=/nethome/files/disc01,automountMapName=auto_direct,ou=services,ou=RBG,dc=foo automountKey: /nethome/files/disc01 objectClass: automount objectClass: top automountInformation: files:/disc01 [...] === /etc/default/autofs: MASTER_MAP_NAME="/etc/auto_direct" TIMEOUT=300 BROWSE_MODE="no" LOGGING="debug" LDAP_URI="ldap://ldap.rbg.foo"; SEARCH_BASE="ou=services,ou=RBG,dc=foo" MAP_OBJECT_CLASS="automountMap" ENTRY_OBJECT_CLASS="automount" MAP_ATTRIBUTE="automountMapName" ENTRY_ATTRIBUTE="automountKey" VALUE_ATTRIBUTE="automountInformation" Debug: Sep 26 10:43:01 clientmaster automount[2081]: autofs stopped Sep 26 10:43:01 clientmaster automount[2102]: Starting automounter version 5.0.7, master map /etc/auto_direct Sep 26 10:43:01 clientmaster automount[2102]: using kernel protocol version 5.02 Sep 26 10:43:01 clientmaster automount[2102]: lookup_nss_read_master: reading master file /etc/auto_direct Sep 26 10:43:01 clientmaster automount[2102]: parse_init: parse(sun): init gathered global options: (null) Sep 26 10:43:01 clientmaster automount[2102]: spawn_mount: mtab link detected, passing -n to mount Sep 26 10:43:01 clientmaster automount[2102]: spawn_umount: mtab link detected, passing -n to mount Sep 26 10:43:01 clientmaster automount[2102]: lookup_read_master: lookup(file): read entry +auto_direct Sep 26 10:43:01 clientmaster automount[2102]: lookup_nss_read_master: reading master ldap auto_direct Sep 26 10:43:01 clientmaster automount[2102]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto_direct". Sep 26 10:43:01 clientmaster automount[2102]: parse_server_string: lookup(ldap): mapname auto_direct Sep 26 10:43:01 clientmaster automount[2102]: parse_ldap_config: lookup(ldap): ldap authentication configured with the following options: Sep 26 10:43:01 clientmaster automount[2102]: parse_ldap_config: lookup(ldap): use_tls: 1, tls_required: 0, auth_required: 1, sasl_mech: (null) Sep 26 10:43:01 clientmaster automount[2102]: parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: (null) credential cache: (null) Sep 26 10:43:01 clientmaster automount[2102]: parse_init: parse(sun): init gathered global options: (null) Sep 26 10:43:01 clientmaster automount[2102]: find_server: trying server uri ldap://ldap.foo Sep 26 10:43:01 clientmaster automount[2102]: do_bind: lookup(ldap): auth_required: 1, sasl_mech (null) Sep 26 10:43:01 clientmaster automount[2102]: do_bind: lookup(ldap): ldap simple bind returned 0 Sep 26 10:43:01 clientmaster automount[2102]: get_query_dn: lookup(ldap): check search base list Sep 26 10:43:01 clientmaster automount[2102]: get_query_dn: lookup(ldap): found search base under ou=services,ou=RBG,dc=foo Sep 26 10:43:01 clientmaster automount[2102]: get_query_dn: lookup(ldap): found query dn automountMapName=auto_direct,ou=services,ou=RBG,dc=foo Sep 26 10:43:01 clientmaster automount[2102]: connected to uri ldap://ldap.foo Sep 26 10:43:01 clientmaster automount[2102]: lookup_read_master: lookup(ldap): searching for "(objectclass=automount)" under "automountMapName=auto_direct,ou=services,ou=RBG,dc=foo" Sep 26 10:43:01 clientmaster automount[2102]: lookup_read_master: lookup(ldap): examining entries Sep 26 10:43:01 clientmaster automount[2102]: syntax error in map near [ /nethome/fire01/disc01 ] Sep 26 10:43:01 clientmaster automount[2102]: syntax error while parsing map. Sep 26 10:43:01 clientmaster automount[2102]: syntax error in map near [ /nethome/fire01/disc02 ] Sep 26 10:43:01 clientmaster automount[2102]: syntax error while parsing map. Sep 26 10:43:01 clientmaster automount[2102]: syntax error in map near [ /nethome/fire01/disc04 ] Sep 26 10:43:01 clientmaster automount[2102]: syntax error while parsing map. Sep 26 10:43:01 clientmaster automount[2102]: syntax error in map near [ /nethome/fire01/disc06 ] Sep 26 10:43:01 clientmaster automount[2102]: syntax error while parsing map. Sep 26 10:43:01 clientmaster automount[2102]: syntax error in map near [ /nethome/files/disc02 ] Sep 26 10:43:01 clientmaster automount[2102]: syntax err
Re: autofs to mount nfs exports
Soul Makossa wrote: > I'm trying to get the following to work on Debian Squeeze 6.6 Although I have previously used the autofs automounter quite a bit now time has passed and my memory has grown vague. But seeing no one else with an answer I will respond hoping to be helpful. > /etc/auto.master: > /- /etc/auto.nfs --ghost > > /etc/auto.nfs > /mnt/nfs1 -fstype=ext3 :/dev/quadstor/M1 That doesn't look right to me. Are you trying to export a device that is itself automounted? I didn't think that was ever supported. I thought you could only export a device that was hard mounted. In any case you can't daisy-chain nfs mount a device that is already presented as an nfs mount. And I believe an automounted device is presented as an nfs mount. At least that is how it used to be. YMMV. > /etc/exports: > /mnt/nfs1 10.0.13.0/255.255.255.0(rw,no_root_squash,no_subtree_check) > > What I'm trying to achieve above is that whenever a nfs client tries to mount > /mnt/nfs1 /dev/quadstor/M1 is automatically mounted. You are trying to have machine A automount machine B and on machine B have it automount a device? As far as I know that behavior does not work and is not supported. > Now the error i get on the client is > > [root@localhost quadstor]# mount -t nfs debian66:/mnt/nfs1 /mnt/iso/ > mount: debian66:/srv/nfs1 failed, reason given by server: Permission denied > > Also exportfs gives the following warning > # exportfs -a > exportfs: Warning: /mnt/nfs1 does not support NFS export. > > At that time df does not list /mnt/nfs1 That is definitely going to be a problem. You can't export it unless it is mounted. If it isn't mounted then it can't be exported. > [root@localhost quadstor]# mount -t nfs debian66:/mnt/nfs1 /mnt/iso/ Normally it is not necessary to specify the "-t nfs" option like that. Simply mount the filesystem. Simple is better. mount debian66:/mnt/nfs1 /mnt/iso > The behavior of exportfs/nfs-server is different than CentOS 6. On > CentOS for the same configuration > > [root@kvm1 rules.d]#exportfs -a > > [root@kvm1 rules.d]# df > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/mapper/vg_kvm1-lv_root > 38744716 6039388 30737200 17% / > tmpfs 768388 0768388 0% /dev/shm > /dev/vda1 495844 23521446723 6% /boot > /dev/sda 103212320192248 9192 1% /mnt/nfs1 > > It seems that running exportfs is sufficient to automatically mount /mnt/nfs1 Are you sure that it wasn't already mounted there? An autofs mounted filesystem presents itself as an nfs filesystem even if it is a local device. It eats its own dogfood and interfaces with the system as an nfs device. This means that an autofs mounted device hasn't been able to be presented again for export. Can't daisy-chain nfs mount an nfs device. Probably CentOS is using a different scheme entirely that isn't autofs to mount that device. If it ends up being mounted directly without an nfs layer then it can be exported. > Am i doing something wrong here ? If you pardon the statement, yes, it looks to me like something isn't right. It looks to me like you are trying to set up an autofs direct map to mount an automounted filesystem. But it has been long enough that I would need to go back and learn all about autofs again in order to know the details. So very sorry but I can't say anything solid. Hopefully someone else will have solid information about your problem. Bob signature.asc Description: Digital signature
Exporting an autofs-mounted filesystem via NFS
Hi,
I've been trying to export an autofs-mounted filesystem via NFS, but I can't
get it to work. Basically when I try to mount such export on the client,
mount.nfs gets stuck and never completes.
Autofs seems to work correctly. because after starting the daemon on the server
and say, doing a "ls", the filesystem gets mounted correctly and I can access
its files. Then I start nfs-kernel-server (when the autofs is already mounted)
and it doesn't report any error (also, if I run showmount --exports on
the client it correclty shows the export).
But when I try to mount it on the client:
# mount.nfs -v 192.168.1.125:/media/Elements /media/Elements
mount.nfs: timeout set for Wed Dec 19 17:21:27 2012
mount.nfs: trying text-based options
'vers=4,addr=192.168.1.125,clientaddr=192.168.1.128'
It gets stuck there until I interrupt it. When I mount the filesystem on the
server manually (without autofs) then the NFS export works correctly.
Here is my configuration:
% cat /etc/auto.master
/media /etc/auto.media --ghost
+dir:/etc/auto.master.d
+auto.master
% cat /etc/auto.media
Elements-fstype=auto,noatimeUUID=x
% cat /etc/exports
/media/Elements 192.168.1.0/24(rw,no_subtree_check)
Is what I'm trying to do even possible?
Cheers
P.S. please CC me, since I'm not subscribed to the list.
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
signature.asc
Description: Digital signature
Re: Autofs and NFS, user mapping
Tom H wrote: > Bob Proulx wrote: > > A pet peeve of mine is "share". Windows has "shares". Unix has > > "filesystems". NFS is itself a Network File System. So saying > > Network File System Share feels like saying a Personal PIN > > Number. It would make me happier if people just referred to > > them as filesystems. > > Share is at least partially right because on Solaris, from where nfs > comes, you create an nfs export with "share ...", exported filesystems > are listed in "/etc/dfs/sharetab", and you list available shares on a > server with "dfshares [server]". Oh... Alright. (head hanging down dejectedly, kicks floor with foot) I should be more tolerant. :-) Thanks! Bob signature.asc Description: Digital signature
Re: Autofs and NFS, user mapping
On Tue, Jul 31, 2012 at 11:20 PM, Bob Proulx wrote: > T o n g wrote: >> Bob Proulx wrote: >>> T o n g wrote: >>>> >>>> My Autofs auto-mounted NFS share looks like this: > > A pet peeve of mine is "share". Windows has "shares". Unix has > "filesystems". NFS is itself a Network File System. So saying > Network File System Share feels like saying a Personal PIN > Number. It would make me happier if people just referred to > them as filesystems. Share is at least partially right because on Solaris, from where nfs comes, you create an nfs export with "share ...", exported filesystems are listed in "/etc/dfs/sharetab", and you list available shares on a server with "dfshares [server]". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SzZwsNytBjd=iPGbGvLzcpGhO5ZY0jS_H=6gNfaV-a=t...@mail.gmail.com
Re: Autofs and NFS, user mapping
On Thu, Aug 2, 2012 at 12:38 AM, T o n g wrote: > On Tue, 31 Jul 2012 10:44:14 -0400, Tom H wrote: >> >> 1) Does the mount work if you export with nfsv3 specified? > > Hmm... that might be the way. How can I do that? > > I remember that I have to specify nfsv3 on the client/nfsmount side to > get the straight-mount work for my uid and gid. On the client, add "nfsvers=3" to the options of your nfs map. OR On the server, add "--no-nfs-version 4" to "RPCMOUNTDOPTS" in "/etc/default/nfs-kernel-server". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sywa_350sgoij4-49apgts_2zyexd_9ciyhpppyhop...@mail.gmail.com
Re: Autofs and NFS, user mapping
On Tue, 31 Jul 2012 10:44:14 -0400, Tom H wrote: > 1) Does the mount work if you export with nfsv3 specified? Hmm... that might be the way. How can I do that? I remember that I have to specify nfsv3 on the client/nfsmount side to get the straight-mount work for my uid and gid. Thanks -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jvd08g$tdi$1...@dough.gmane.org
Re: Autofs and NFS, user mapping
T o n g wrote: > Bob Proulx wrote: > > T o n g wrote: > >> My Autofs auto-mounted NFS share looks like this: A pet peeve of mine is "share". Windows has "shares". Unix has "filesystems". NFS is itself a Network File System. So saying Network File System Share feels like saying a Personal PIN Number. It would make me happier if people just referred to them as filesystems. > >> drwxr-xr-x 9 4294967294 4294967294 45056 2011-04-12 09:47 tmp/ Of course that looks like either the 'nobody' user and group or it looks like a -1 error being propagated. Probably just the nobody user and group. > >> I.e., the user id and group id are all mapped wrong. Because you said the user id and group id are mapped wrong I suggested to be aware of the --manage-gids option because it changes the behavior of how users and groups are looked up. For me it is a source of problem because I don't usually give users accounts on the NFS server machines. But if --manage-gids is in effect then I would need to in order to have the server look up their account data. For me that is "just wrong". However for the bug reporter that I referenced not having all of the groups were for them "just wrong" too. The solution is mutually exclusive. One or the other works but not both. > >> I have identical user ids and groups between my NFS sharing stations, Just say "workstations that have the same NFS filesystem mounted" or something to that effect. > So you are saying to remove it? No. I am not sure that is your problem. It might be. Not sure. You didn't include enough information for anyone to know. But since you have that information and looking at the way the --manage-gids works should be able to tell if that is your issue or not. It definitely changes the way account data is looked up. > I did that and restarted my nfs-kernel-server. Now: > > $ ps -ef | grep rpc.mountd > root 12869 1 0 Jul30 ?00:00:00 /usr/sbin/rpc.mountd > > However, on the client side, Autofs still show the wrong uid and gid. > Same as in OP. Then that is not your problem. I think you have improved things though. > Anywhere else to check? Let's back up and start through the debug path. 'ls' is going to stat(2) calls to look up information about those files. The user and group displayed are mapped through the number stored in the file's inode metadata. You can see the actual numbers by using the 'ls -n' option. Or by using 'stat'. $ ls -ldn yourfoo drwxr-xr-x 60 1000 1000 4096 Jul 31 18:59 yourfoo $ stat youfoo File: `yourfoo' Size: 4096Blocks: 8 IO Block: 4096 directory Device: fe02h/65026dInode: 3932162 Links: 60 Access: (0755/drwxr-xr-x) Uid: ( 1000/ rwp) Gid: ( 1000/ rwp) Access: 2012-07-31 12:44:16.104414486 -0600 Modify: 2012-07-31 18:59:12.254911408 -0600 Change: 2012-07-31 18:59:12.254911408 -0600 See the user and group numbers? The "1000". That is my user id. After obtaining the number the ls program will look up the matching name assocatied with that number. In Unix everything is done with the number. But people like the name to be displayed. To look up the number from the command line there are a number of different tools and different ways. GNU glibc provides 'getent' specifically for this purpose so I will quote it. But with NIS/yp it would be ypcat or ypmatch. With a traditional Unix system it would simply be 'grep' of the account from /etc/passwd. $ getent passwd 1000 rwp:x:1000:1000:Bob Proulx,,,:/home/rwp:/bin/bash $ getent group 1000 rwp:x:1000: So that completes path from getting the user and group numbers assocatied with a file. (And directories are simply files. Just special files.) And then converting the number to a name. If the number does not have an associated name in the password or group databases (/etc/passwd or /etc/group files) then the number itself is printed. With the above hints what is going on with your system? Bob signature.asc Description: Digital signature
Re: Autofs and NFS, user mapping
On Sun, Jul 29, 2012 at 2:37 PM, T o n g wrote: > > My Autofs auto-mounted NFS share looks like this: > > drwxr-xr-x 9 4294967294 4294967294 45056 2011-04-12 09:47 tmp/ > > I.e., the user id and group id are all mapped wrong. > > I have identical user ids and groups between my NFS sharing stations, so > previously, prior to using Autofs I just use the NFS ver3 direct mapping, > without specifying any user mapping schemes, and it works nicely. > > Now I started to use Autofs, but everything get messed up. I've read many > web pages, but none of them mentioned about this problem. > I also tried to specify "uid=1000,gid=1000,allow_other", which I found in > https://help.ubuntu.com/community/Autofs/, but it doesn't work for my nfs. 1) Does the mount work if you export with nfsv3 specified? 2) Does the mount work if you export with fsid=0 specified? (Keeping in mind that if you specify that "/path/to/export" is exported with "fsid=0", the mount of "/path/to/export" is "/".) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sz__irjhxfzdsnaf-1sabttj5yq23bydyrzrebubpm...@mail.gmail.com
Re: Autofs and NFS, user mapping
On Sun, 29 Jul 2012 18:06:31 -0600, Bob Proulx wrote: > T o n g wrote: >> My Autofs auto-mounted NFS share looks like this: >> >> drwxr-xr-x 9 4294967294 4294967294 45056 2011-04-12 09:47 tmp/ >> >> I.e., the user id and group id are all mapped wrong. >> >> I have identical user ids and groups between my NFS sharing stations, >> so previously, prior to using Autofs I just use the NFS ver3 direct >> mapping, without specifying any user mapping schemes, and it works >> nicely. > > Do you have --manage-gids in /etc/default/nfs-kernel-server set? > > $ ps -ef | grep rpc.mountd > root 1527 1 0 Jul10 ?00:00:33 /usr/sbin/rpc.mountd > --manage-gids > > While this is a bug fix[1] for some it is a bug source for me. > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493059 Thanks for your replay, Bob. I have that too. $ ps -ef | grep rpc.mountd root 1539 1 0 Jul07 ?00:00:00 /usr/sbin/rpc.mountd -- manage-gi So you are saying to remove it? I did that and restarted my nfs-kernel-server. Now: $ ps -ef | grep rpc.mountd root 12869 1 0 Jul30 ?00:00:00 /usr/sbin/rpc.mountd However, on the client side, Autofs still show the wrong uid and gid. Same as in OP. Anywhere else to check? Thanks -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jv7lgn$n9$1...@dough.gmane.org
Re: Autofs and NFS, user mapping
T o n g wrote: > My Autofs auto-mounted NFS share looks like this: > > drwxr-xr-x 9 4294967294 4294967294 45056 2011-04-12 09:47 tmp/ > > I.e., the user id and group id are all mapped wrong. > > I have identical user ids and groups between my NFS sharing stations, so > previously, prior to using Autofs I just use the NFS ver3 direct mapping, > without specifying any user mapping schemes, and it works nicely. Do you have --manage-gids in /etc/default/nfs-kernel-server set? $ ps -ef | grep rpc.mountd root 1527 1 0 Jul10 ?00:00:33 /usr/sbin/rpc.mountd --manage-gids While this is a bug fix[1] for some it is a bug source for me. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493059 Bob signature.asc Description: Digital signature
Autofs and NFS, user mapping
Hi, My Autofs auto-mounted NFS share looks like this: drwxr-xr-x 9 4294967294 4294967294 45056 2011-04-12 09:47 tmp/ I.e., the user id and group id are all mapped wrong. I have identical user ids and groups between my NFS sharing stations, so previously, prior to using Autofs I just use the NFS ver3 direct mapping, without specifying any user mapping schemes, and it works nicely. Now I started to use Autofs, but everything get messed up. I've read many web pages, but none of them mentioned about this problem. I also tried to specify "uid=1000,gid=1000,allow_other", which I found in https://help.ubuntu.com/community/Autofs/, but it doesn't work for my nfs. Anyway, please help. Thanks -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jv3vt4$mr$1...@dough.gmane.org
sshfs via autofs permissions problem
Hi, I'm using 2 Debian Squeeze as web server. On server1 I have a folder of user uploaded data (a Django user media folder to be exact) where everything belongs to www-data and this user can read write. Now on server2 which is a clone that is used over load balancing I am trying to set up sshfs via autofs. Right now it seems to be working but actually I must have done something wrong because if I login with www-data on server2 and go to the user media directory which is owned by www-data I get a permission denied when I try to write. This is my /etc/auto.master: /home/server2/user_media /etc/auto.sshfs --timeout=30,--ghost +auto.master and this is my /etc/auto.sshfs: mountpoint -fstype=fuse,rw,nodev,nonempty,allow_other,reconnect,uid=33,gid=33,max_read=65536,compression=yes,auto_cache,no_check_root,kernel_cache :sshfs\#server1@server1:/home/server1/user_media 33 is www-data uig and gid on both servers. I have tried various options like putting uid and gid in the auto.master or using idmap=user in the auto.sshfs but I have never been able to write with the www-data user on server2 in the shared folder. Could anybody please shed some light?
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
On Mi, 07 mar 12, 13:30:12, Sylvain wrote: > 2012/3/7 Camaleón : > > Anyway, I would have expected some kind of warning at the logs coming > > from backuppc indicating a problem for accessing to the configured mount > > point which was not available at that time and thus failing. > > Me too, and I didn't understand why I wasn't getting anything in the > logs until now: the default LogDir (/var/lib/backuppc/log/) is in a > subdirectory of the TopDir (/var/lib/backuppc/), which means that if > the TopDir doesn't exist, backuppc won't be able to log the error in > LogDir. So in order to check the logs to find out what the problem is > you first have to solve the problem. :-) [Note: I know nothing about backuppc] If having /var/lib/backuppc on media that may or may not be available during startup is common, then I guess this is a bug in backuppc (documentation, configuration, behaviour, etc.). On the other hand /var and subdirs are usually local[1], in which case you just shot yourself in the foot (which Linux and associated software traditionally does allow). [1] in this context I don't consider removable media that may or may not be connected to be local Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
On Wed, 07 Mar 2012 13:30:12 +0100, Sylvain wrote: > 2012/3/7 Camaleón : >> Anyway, I would have expected some kind of warning at the logs coming >> from backuppc indicating a problem for accessing to the configured >> mount point which was not available at that time and thus failing. > > Me too, and I didn't understand why I wasn't getting anything in the > logs until now: the default LogDir (/var/lib/backuppc/log/) is in a > subdirectory of the TopDir (/var/lib/backuppc/), which means that if the > TopDir doesn't exist, backuppc won't be able to log the error in LogDir. > So in order to check the logs to find out what the problem is you first > have to solve the problem. :-) There is "/var/log/syslog" for that kind of purpose. Why is not used, I can't tell :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jj7kpu$ujn$7...@dough.gmane.org
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
2012/3/7 Camaleón : > Anyway, I would have expected some kind of warning at the logs coming > from backuppc indicating a problem for accessing to the configured mount > point which was not available at that time and thus failing. Me too, and I didn't understand why I wasn't getting anything in the logs until now: the default LogDir (/var/lib/backuppc/log/) is in a subdirectory of the TopDir (/var/lib/backuppc/), which means that if the TopDir doesn't exist, backuppc won't be able to log the error in LogDir. So in order to check the logs to find out what the problem is you first have to solve the problem. :-) Cheers, Sylvain -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJwBQFNYny=wdQUBKPCi_Mc4bN1-R=kkU_=T=oftvzlbdnv...@mail.gmail.com
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
On Wed, 07 Mar 2012 08:46:23 +0100, Sylvain wrote: > 2012/3/6 Camaleón : >> Well, there are some packages that in addition to be installed have to >> be configured to be run on booting. I mean, the fact a service is not >> started by default cannot be considered a bug or error "per se". > > Sure, but you usually have either configuration files to edit, or a note > in the readme file stating that you'll need some additional steps to > make the package work if you're using some special configuration. Yes, but this does not seem to be the case. What I wanted to note is that an installed package does not have to be enabled by default, it can need manual intervention. > Also the resolution of the problem was not straightforward; in fact I > was writing to the list to get a solution to my problem when the > solution came to my mind. "Problems" and "straightforward" do not usually go in the same phrase, by their own nature :-) >> So backuppc daemon is starting but fails because it cannot access to >> the configured external USB hard disk? You can check the service status >> with "service backuppc status". > > Yes, the /removable/sbackup/backuppc directory is empty since autofs has > not started yet and thus has not created the directory yet. Okay, then the service is started but fails. >> Mmm, I would open a bug against the package it self (that is, backuppc) >> to get some feedback from the package maintainers about this situation. >> >> In principle (though I don't know BackupPC requirements in deep), it >> should not require "autofs" by default (nor smb, nfs...) because there >> can be people/installations not having that service even installed. > > Sure. Maybe the best solution is a note in the readme file for autofs > users. I'll file a bugreport against backuppc. Sure, documenting that kind of things never hurts. Anyway, I would have expected some kind of warning at the logs coming from backuppc indicating a problem for accessing to the configured mount point which was not available at that time and thus failing. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jj7jul$ujn$5...@dough.gmane.org
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
On Wed, Mar 7, 2012 at 2:46 AM, Sylvain wrote: > 2012/3/6 Tom H : >> >> AFAICT, a bug should be filed against backuppc to change its init >> script to have "$remote_fs" (or "$all"!) in "Required-Start" or >> "autofs" in "Should-Start". > > autofs doesn't seem to be included in $remote_fs, and autofs doen't > have anything to do with backuppc so I don't think it should be > included in backuppc's init script. I'm surprised that autofs isn't in "$remote_fs"; maybe it's in "$network" but I have no idea how to check either and I'll take your word for it. You misunderstand the LSB headers and insserv. It doesn't matter whether aufofs and backuppc are related; insserv has to have whatever infomation's required to order the init scripts in "rcX.d" properly. For example, nfs-kernel-server has "named" or "$named" (I'm not sure) in "Should-Start". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SyGMOs88u+Ci-aCXY1mRFPJA===pxhmh5ft3ybccmo...@mail.gmail.com
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
2012/3/6 Tom H : > AFAICT, a bug should be filed against backuppc to change its init > script to have "$remote_fs" (or "$all"!) in "Required-Start" or > "autofs" in "Should-Start". autofs doesn't seem to be included in $remote_fs, and autofs doen't have anything to do with backuppc so I don't think it should be included in backuppc's init script. 2012/3/6 Camaleón : > On Tue, 06 Mar 2012 12:35:21 +0100, Sylvain wrote: > >> I installed backuppc the other day, configured it and it works fine >> except for one thing: it doesn't start at boot. I looked in the backuppc >> logs and in the syslog and saw nothing suspicious. If I start it >> manually with /etc/init.d/backuppc start, it works just fine. There are >> also startup scripts in /etc/rc*.d/. My backuppc version is 3.2.1-2 (I'm >> running a testing install). > > Well, there are some packages that in addition to be installed have to be > configured to be run on booting. I mean, the fact a service is not > started by default cannot be considered a bug or error "per se". Sure, but you usually have either configuration files to edit, or a note in the readme file stating that you'll need some additional steps to make the package work if you're using some special configuration. Also the resolution of the problem was not straightforward; in fact I was writing to the list to get a solution to my problem when the solution came to my mind. >> Note that my /var/lib/backuppc directory points to >> /removable/sbackup/backuppc which is my external USB HDD mounted by >> autofs, which is in /etc/rc*.d/S21autofs (backuppc is >> /etc/rc*.d/S21backuppc). After some investigation I found that adding >> autofs in the Required-Start section of the insserv overrides of the >> backuppc init script solved the problem. > > So backuppc daemon is starting but fails because it cannot access to the > configured external USB hard disk? You can check the service status with > "service backuppc status". Yes, the /removable/sbackup/backuppc directory is empty since autofs has not started yet and thus has not created the directory yet. >> Now I'm not sure how to report >> the bug. Should I report it against autofs (so that autofs gets included >> into $local_fs or in the mountall.sh script but these scripts have >> nothing to do with autofs), or in insserv (again so that autofs gets >> included into $local_fs, but insserv doesn't have anything to do with >> autofs) or in backuppc so that the init script is modified (but again, >> backuppc has nothing to do with autofs)? > > Mmm, I would open a bug against the package it self (that is, backuppc) > to get some feedback from the package maintainers about this situation. > > In principle (though I don't know BackupPC requirements in deep), it > should not require "autofs" by default (nor smb, nfs...) because there > can be people/installations not having that service even installed. Sure. Maybe the best solution is a note in the readme file for autofs users. I'll file a bugreport against backuppc. Thanks for the hints, Sylvain -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJwBQFN6GNUmyPDE=mDrYpP4Sd0f3=z3ocm4lf6yqgpb00s...@mail.gmail.com
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
On Tue, 06 Mar 2012 12:35:21 +0100, Sylvain wrote: > I installed backuppc the other day, configured it and it works fine > except for one thing: it doesn't start at boot. I looked in the backuppc > logs and in the syslog and saw nothing suspicious. If I start it > manually with /etc/init.d/backuppc start, it works just fine. There are > also startup scripts in /etc/rc*.d/. My backuppc version is 3.2.1-2 (I'm > running a testing install). Well, there are some packages that in addition to be installed have to be configured to be run on booting. I mean, the fact a service is not started by default cannot be considered a bug or error "per se". > Note that my /var/lib/backuppc directory points to > /removable/sbackup/backuppc which is my external USB HDD mounted by > autofs, which is in /etc/rc*.d/S21autofs (backuppc is > /etc/rc*.d/S21backuppc). After some investigation I found that adding > autofs in the Required-Start section of the insserv overrides of the > backuppc init script solved the problem. So backuppc daemon is starting but fails because it cannot access to the configured external USB hard disk? You can check the service status with "service backuppc status". > Now I'm not sure how to report > the bug. Should I report it against autofs (so that autofs gets included > into $local_fs or in the mountall.sh script but these scripts have > nothing to do with autofs), or in insserv (again so that autofs gets > included into $local_fs, but insserv doesn't have anything to do with > autofs) or in backuppc so that the init script is modified (but again, > backuppc has nothing to do with autofs)? Mmm, I would open a bug against the package it self (that is, backuppc) to get some feedback from the package maintainers about this situation. In principle (though I don't know BackupPC requirements in deep), it should not require "autofs" by default (nor smb, nfs...) because there can be people/installations not having that service even installed. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jj5kvp$ds9$2...@dough.gmane.org
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
On Tue, Mar 6, 2012 at 6:35 AM, Sylvain wrote: > > I installed backuppc the other day, configured it and it works fine > except for one thing: it doesn't start at boot. I looked in the > backuppc logs and in the syslog and saw nothing suspicious. If I start > it manually with /etc/init.d/backuppc start, it works just fine. There > are also startup scripts in /etc/rc*.d/. My backuppc version is > 3.2.1-2 (I'm running a testing install). > > Note that my /var/lib/backuppc directory points to > /removable/sbackup/backuppc which is my external USB HDD mounted by > autofs, which is in /etc/rc*.d/S21autofs (backuppc is > /etc/rc*.d/S21backuppc). After some investigation I found that adding > autofs in the Required-Start section of the insserv overrides of the > backuppc init script solved the problem. Now I'm not sure how to > report the bug. Should I report it against autofs (so that autofs gets > included into $local_fs or in the mountall.sh script but these scripts > have nothing to do with autofs), or in insserv (again so that autofs > gets included into $local_fs, but insserv doesn't have anything to do > with autofs) or in backuppc so that the init script is modified (but > again, backuppc has nothing to do with autofs)? autofs *usually* mounts remote filesystems so including it in "$local_fs" doesn't make sense. AFAICT, a bug should be filed against backuppc to change its init script to have "$remote_fs" (or "$all"!) in "Required-Start" or "autofs" in "Should-Start". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=swmkbe6y38k3ceiofnxurtjehopkva03s7rd13mda7...@mail.gmail.com
Re: How to report a bug related to multiple packages (insserv, autofs, backuppc)
On 06/03/12 11:35, Sylvain wrote: Hey there, I installed backuppc the other day, configured it and it works fine except for one thing: it doesn't start at boot. I looked in the backuppc logs and in the syslog and saw nothing suspicious. If I start it manually with /etc/init.d/backuppc start, it works just fine. There are also startup scripts in /etc/rc*.d/. My backuppc version is 3.2.1-2 (I'm running a testing install). Note that my /var/lib/backuppc directory points to /removable/sbackup/backuppc which is my external USB HDD mounted by autofs, which is in /etc/rc*.d/S21autofs (backuppc is /etc/rc*.d/S21backuppc). After some investigation I found that adding autofs in the Required-Start section of the insserv overrides of the backuppc init script solved the problem. Now I'm not sure how to report the bug. Should I report it against autofs (so that autofs gets included into $local_fs or in the mountall.sh script but these scripts have nothing to do with autofs), or in insserv (again so that autofs gets included into $local_fs, but insserv doesn't have anything to do with autofs) or in backuppc so that the init script is modified (but again, backuppc has nothing to do with autofs)? Thanks for your advice, Sylvain I think I would call that configuration, not a bug. How would backuppc know the drive is connected & switched on, if you don't tell it. :) (Others may need it to run as a cron job; they may backup to tape, etc.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f55fe54.3010...@gmail.com
How to report a bug related to multiple packages (insserv, autofs, backuppc)
Hey there, I installed backuppc the other day, configured it and it works fine except for one thing: it doesn't start at boot. I looked in the backuppc logs and in the syslog and saw nothing suspicious. If I start it manually with /etc/init.d/backuppc start, it works just fine. There are also startup scripts in /etc/rc*.d/. My backuppc version is 3.2.1-2 (I'm running a testing install). Note that my /var/lib/backuppc directory points to /removable/sbackup/backuppc which is my external USB HDD mounted by autofs, which is in /etc/rc*.d/S21autofs (backuppc is /etc/rc*.d/S21backuppc). After some investigation I found that adding autofs in the Required-Start section of the insserv overrides of the backuppc init script solved the problem. Now I'm not sure how to report the bug. Should I report it against autofs (so that autofs gets included into $local_fs or in the mountall.sh script but these scripts have nothing to do with autofs), or in insserv (again so that autofs gets included into $local_fs, but insserv doesn't have anything to do with autofs) or in backuppc so that the init script is modified (but again, backuppc has nothing to do with autofs)? Thanks for your advice, Sylvain -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJwBQFNR=CNtB43SE=-ggizrl8ehqeqgsfruawskjkqmjj8...@mail.gmail.com
Re: autofs interest ?
Stephane Durieux wrote: > A simple question: > from a server point of view does autofs costs less (cpu, io, memory) > than "traditionnal" nfs ? AutoFS is simply a automated mount service for NFS. AutoFS doesn't replace NFS. The autofs simply gets nfs going by mounting remote nfs filesystems on demand. Therefore it will never cost more nor less not using it with NFS. The server in particular does not run autofs and so it does not matter there at all. Using AutoFS is very traditional. However the automounter is often a source of problems of its own. Often it will fail to mount a particular filesystem or it will unmount one filesystem of a set and fail to mount it back again. When it works it is wonderful. When it does not work it is a PITA. > From a client point of view I think the fact to unmount directories > frees ressources? Yes. And most importantly reduces the total amount of time that the nfs client is active. That reduces the opportunity for the nfs client to get into a bad state and require that the client host be rebooted. The nfs client getting into a bad state is the most likely reason to require a reboot. Not having the nfs client running makes the system more stable. > But does a moint point consumes so much (memory ?) I don't know the total amount but I never found it significant. > And concerning the network What about the network? > Thanks for explanation (or the little course) I use the automounter in a large corporate environment. There are hundreds of machines potentially possible to be mounted. But at any point only two or three are actually needed. Using the automounter simplifies this large nfs configuration. But it comes at a cost of complexity. The automounter sometimes causes its own problems. There are three types of automount maps. Direct, Indirect, and Host. Direct maps are the most reliable and the least trouble but most configuration. Indirect maps are simpler and have various advantages but also have some problems. Host maps are easiest and also have the most problems. Asking about the autofs means you need to be thinking about what type of automounter mapping configuration you will be using. You should also want to look at the Berkeley Automouter 'amd' too for an alternative implementation. The two designs each have their own advantages and disadvantages. Bob signature.asc Description: Digital signature
autofs interest ?
Hello, A simple question: from a server point of view does autofs costs less (cpu, io, memory) than "traditionnal" nfs ? From a client point of view I think the fact to unmount directories frees ressources? But does a moint point consumes so much (memory ?) And concerning the network Thanks for explanation (or the little course)
shutdown problem in combination with autofs/NFS
Hello, occassionally our Debian 6 boxes don't shutdown. The shutdown process hangs forever with the last messages: Turning off quotas:...Checking for running unattended-upgrades: I assume, I found the reason for this issue, but no solution. Our linux computers mount some directories via NFS. The directories /home and /sw are managed by the automounter. /usr/local is a symlink to /sw/local.debian-6 which is mounted from the NFS server. While shutting down, sometimes the automounter finishes to early. Afterwards all scripts in /etc/init.d which look for binaries in /usr/local/bin hang. Until Debian 5 this wasn't an issue, because the automounter finishes at a well defined time relatively to other services. But with the new dependency based init system, this time seems to vary and sometimes the automounter finishes to early. If this situation occurs, all local terminals are dead and can be used for debugging. But from an open ssh session I can restart autofs and then the shutdown goes further. First I tried to remove /usr/local/bin from the PATH variable in /etc/profiles. But this doesn't not help, because a lot of init scripts define theire own PATH variable: # grep -l "PATH.*/usr/local/bin" /etc/init.d/* /etc/init.d/alsa-utils /etc/init.d/apache2 /etc/init.d/binfmt-support /etc/init.d/cpufrequtils /etc/init.d/cups /etc/init.d/hal /etc/init.d/ipmievd /etc/init.d/libvirt-bin /etc/init.d/networking /etc/init.d/quota /etc/init.d/quotarpc /etc/init.d/saned /etc/init.d/schroot /etc/init.d/sysstat /etc/init.d/unattended-upgrades Next we tried to adjust the dependencies in /etc/init.d/autofs. But we didn't found a working solution. Is there a simple solution or workaround for this? I didn't filed a bug until now, because of the nonstandard configuration with /usr/local via NFS/autofs. Or should I do this? Ingo Rogalsky -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e42640e.70...@web.de
Re: Problems with autofs
On Fri, Apr 15, 2011 at 10:59 AM, Aniruddha wrote: > On Tue, Apr 12, 2011 at 11:07 PM, Klistvud wrote: >> Dne, 12. 04. 2011 20:52:08 je Aniruddha napisal(a): > >>> I tried with and without quotes, with the label and formatting the >>> drive as ext3. I restarted autofs. None of these worked. When I cd to >>> /var/autofs/removable it's empty. >> >> It's supposed to be empty. After you cd to it, try issuing: >> ls usb >> >> Or, even better, use the --ghost option in your auto.master, like this: >> >> /var/autofs/removable /etc/auto.removable >> --timeout=2,sync,nodev,nosuid,ghost >> > Both suggestions didn't work. If I understand correctly my config > files are correct? auto has never worked for me, as you're any ways mounting it through UUID, you can specify the actual FS, in this case vfat. Try it and think it'll work out... Thanks, -- Javier. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinr3ojwq7ehygxbr2hvvw6t3w8...@mail.gmail.com
Re: Problems with autofs
On Tue, Apr 12, 2011 at 11:07 PM, Klistvud wrote: > Dne, 12. 04. 2011 20:52:08 je Aniruddha napisal(a): >> I tried with and without quotes, with the label and formatting the >> drive as ext3. I restarted autofs. None of these worked. When I cd to >> /var/autofs/removable it's empty. > > It's supposed to be empty. After you cd to it, try issuing: > ls usb > > Or, even better, use the --ghost option in your auto.master, like this: > > /var/autofs/removable /etc/auto.removable > --timeout=2,sync,nodev,nosuid,ghost > Both suggestions didn't work. If I understand correctly my config files are correct? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinv5hwgbf_iaoog7_tgwfvqu-s...@mail.gmail.com
Re: Problems with autofs
Dne, 12. 04. 2011 20:52:08 je Aniruddha napisal(a): Thanks for the help! On Tue, Apr 12, 2011 at 7:38 PM, Klistvud wrote: > The quotes around the UUID may be superfluous. > Try with LABEL=KINGSTON if you can't make it work with UUID...? > Then again, Linux may just plain hate vfat... I tried with and without quotes, with the label and formatting the drive as ext3. I restarted autofs. None of these worked. When I cd to /var/autofs/removable it's empty. It's supposed to be empty. After you cd to it, try issuing: ls usb Or, even better, use the --ghost option in your auto.master, like this: /var/autofs/removable /etc/auto.removable --timeout=2,sync,nodev,nosuid,ghost My current settings: # cat /etc/auto.master /var/autofs/removable /etc/auto.removable --timeout=2,sync,nodev,nosuid # cat /etc/auto.removable usb -fstype=auto UUID=b5fe478b-26f5-4182-a264-ba2b0a7c33c8 # blkid /dev/sdc1 /dev/sdc1: LABEL="KINGSTON" UUID="b5fe478b-26f5-4182-a264-ba2b0a7c33c8" SEC_TYPE="ext2" TYPE="ext3" -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1302642420.3942.1@compax
Re: Problems with autofs
Thanks for the help! On Tue, Apr 12, 2011 at 7:38 PM, Klistvud wrote: > The quotes around the UUID may be superfluous. > Try with LABEL=KINGSTON if you can't make it work with UUID...? > Then again, Linux may just plain hate vfat... I tried with and without quotes, with the label and formatting the drive as ext3. I restarted autofs. None of these worked. When I cd to /var/autofs/removable it's empty. My current settings: # cat /etc/auto.master /var/autofs/removable /etc/auto.removable --timeout=2,sync,nodev,nosuid # cat /etc/auto.removable usb -fstype=auto UUID=b5fe478b-26f5-4182-a264-ba2b0a7c33c8 # blkid /dev/sdc1 /dev/sdc1: LABEL="KINGSTON" UUID="b5fe478b-26f5-4182-a264-ba2b0a7c33c8" SEC_TYPE="ext2" TYPE="ext3" -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikpb+yw3m1fqszgdbhdz9jptgd...@mail.gmail.com
Re: Problems with autofs
Dne, 12. 04. 2011 17:39:35 je Aniruddha napisal(a): I try to automagically mount an usb drive following the autofs instructions in the wiki ( http://wiki.debian.org/AutoFs ). For some reason it just doesn't work. I can't find any relevant error message in messages or syslog. Any ideas where I can begin to troubleshoot? Thanks! # cat /etc/auto.master /var/autofs/removable /etc/auto.removable --timeout=2,sync,nodev,nosui Is that the only line in your auto.master? Have you checked in /var/autofs/removable? Have you restarted autofs? # cat /etc/auto.removable usb -fstype=auto UUID="7DF2-7401" The quotes around the UUID may be superfluous. # lsmod | grep autofs autofs424072 1 # blkid /dev/sdc1 /dev/sdc1: LABEL="KINGSTON" UUID="7DF2-7401" TYPE="vfat" Try with LABEL=KINGSTON if you can't make it work with UUID...? Then again, Linux may just plain hate vfat... -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1302629888.3942.0@compax
Problems with autofs
I try to automagically mount an usb drive following the autofs instructions in the wiki ( http://wiki.debian.org/AutoFs ). For some reason it just doesn't work. I can't find any relevant error message in messages or syslog. Any ideas where I can begin to troubleshoot? Thanks! # cat /etc/auto.master /var/autofs/removable /etc/auto.removable --timeout=2,sync,nodev,nosui # cat /etc/auto.removable usb -fstype=auto UUID="7DF2-7401" # lsmod | grep autofs autofs424072 1 # blkid /dev/sdc1 /dev/sdc1: LABEL="KINGSTON" UUID="7DF2-7401" TYPE="vfat"
Re: Autofs not respecting uid in auto.removable
On Sat, 05 Mar 2011 19:28:39 +0530, L V Gandhi wrote: > On Sat, Mar 5, 2011 at 5:21 PM, Camaleón wrote: >> > Any solutions to mount with ownership of user? >> >> As per "man 5 autofs": >> >> (...) >> >> If you use the automounter for a filesystem without access permissions >> (like vfat), users usually can't write on such a filesystem because it >> is mounted as user root. You can solve this problem by passing the >> option gid=, e.g. gid=floppy. The filesystem is then mounted as >> group floppy instead of root. Then you can add the users to this group, >> and they can write to the filesystem. Here's an example entry for an >> autofs map: >> >> floppy-vfat -fstype=vfat,sync,gid=floppy,umask=002 :/dev/fd0 *** > Thanks again for your time in helping. However I have achived what I > wanted by using udev rules as mentioned in > http://okomestudio.net/biboroku/?p=1402 Ah, good. Autofs should also work fine, just it needs the GID, as manual says, when it comes to vfat volumes. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.03.05.14.58...@gmail.com
Re: Autofs not respecting uid in auto.removable
Thanks again for your time in helping. However I have achived what I wanted by using udev rules as mentioned in http://okomestudio.net/biboroku/?p=1402 On Sat, Mar 5, 2011 at 5:21 PM, Camaleón wrote: > On Sat, 05 Mar 2011 07:39:32 +0530, L V Gandhi wrote: > > > I am running squeeze. > > I have following lines in /etc/auto.removable > > lvgandhi@lvgvaio:~$ cat /etc/auto.removable > > (...) > > > ehd -fstype=vfat,rw,uid=1000,umask=022,posix,shortname=winnt > :/dev/ehd > > #ehd-fstype=vfat,rw,uid=1000,umask=022,posix,shortname=winnt > UUID=84C0-F18B > > (...) > > > Any solutions to mount with ownership of user? > > As per "man 5 autofs": > > (...) > > If you use the automounter for a filesystem without access permissions > (like vfat), users usually can't write on such a filesystem because it is > mounted as user root. You can solve this problem by passing the option > gid=, e.g. gid=floppy. The filesystem is then mounted as group > floppy instead of root. Then you can add the users to this group, and > they can write to the filesystem. Here's an example entry for an autofs > map: > > floppy-vfat -fstype=vfat,sync,gid=floppy,umask=002 :/dev/fd0 > *** > > HTH. > > Greetings, > > -- > Camaleón > > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/pan.2011.03.05.11.51...@gmail.com > > -- L V Gandhi
Re: Autofs not respecting uid in auto.removable
On Sat, 05 Mar 2011 07:39:32 +0530, L V Gandhi wrote: > I am running squeeze. > I have following lines in /etc/auto.removable > lvgandhi@lvgvaio:~$ cat /etc/auto.removable (...) > ehd -fstype=vfat,rw,uid=1000,umask=022,posix,shortname=winnt :/dev/ehd > #ehd-fstype=vfat,rw,uid=1000,umask=022,posix,shortname=winnt > UUID=84C0-F18B (...) > Any solutions to mount with ownership of user? As per "man 5 autofs": (...) If you use the automounter for a filesystem without access permissions (like vfat), users usually can't write on such a filesystem because it is mounted as user root. You can solve this problem by passing the option gid=, e.g. gid=floppy. The filesystem is then mounted as group floppy instead of root. Then you can add the users to this group, and they can write to the filesystem. Here's an example entry for an autofs map: floppy-vfat -fstype=vfat,sync,gid=floppy,umask=002 :/dev/fd0 *** HTH. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.03.05.11.51...@gmail.com
Autofs not respecting uid in auto.removable
I am running squeeze. I have following lines in /etc/auto.removable lvgandhi@lvgvaio:~$ cat /etc/auto.removable flash -fstype=vfat,rw,uid=1000,umask=022,posix,shortname=winnt :/dev/flash ehd -fstype=vfat,rw,uid=1000,umask=022,posix,shortname=winnt :/dev/ehd #ehd-fstype=vfat,rw,uid=1000,umask=022,posix,shortname=winnt UUID=84C0-F18B I tried both /dev/ehd and UUID methods. /var/autofs/removable/ehd is mounted as root.root. I tried chown as sudo. There also I failed. lvgandhi@lvgvaio:~$ sudo chown lvgandhi /var/autofs/removable/ehd chown: changing ownership of `/var/autofs/removable/ehd': Operation not permitted Any solutions to mount with ownership of user? -- L V Gandhi
Re: Monitoring AutoFS in SNMP
--- On Tue, 3/23/10, Brian wrote: > From: Brian > Subject: Monitoring AutoFS in SNMP > To: "Debian User" > Date: Tuesday, March 23, 2010, 10:00 AM > I am trying to find a MIB to monitor > AutoFS but everything I find is tied to the current pid > AutoFS is running under which of course changes each time it > is restarted making it useless as a monitoring metric. > > Has anyone setup SNMP to monitor AutoFS or a similar type > of daemon on a Debain system? > > Thanks, > > Brian > I ran across the solution to this and thought I would share it. By default Debian systems are not configured to have processes monitored by SNMP but it can be enabled by editing the /etc/snmp/snmpd.conf file. To do so look for the Process checks section about a third of the way down in the file and to monitor autofs you would enter something like this: proc automount You can do something more sophisticated if you wish but it is not necessary. There is plenty of documentation within the snmpd.conf file that you really don't have to go anywhere else for more information in most applications. Once again the Debian developers have made it so blatantly obvious that I completely missed it. I am sure the package maintainer is shaking their fist at the sky yelling, "Just how simple do I have to make it!" Debian is the best. Thanks all, Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/743956.21210...@web33803.mail.mud.yahoo.com
RE: Monitoring AutoFS in SNMP
> If it spawns a new process each time it mounts a new > partition, would it > not have a parent process that would at least be constant > on the server? > If that's the case, maybe you should just monitor the > parent process. > Otherwise, it would make sense to monitor a partition > instead of a pid > for a specific spawned process. > > James > It looks like the parent process snmp mib is also tied to it's pid and would change whenever the daemon is restarted. I am beginning to wonder if you can monitor Debian daemons at all with snmp. Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/358448.84179...@web33804.mail.mud.yahoo.com
RE: Monitoring AutoFS in SNMP
> We are using autofs to mount cdrom and dvd iso images. There > are nearly 100 of them. Too many to really monitor > individually so we wanted to just monitor autofs. It looks > to me like each auto.* file in /etc spawns it's own process > and pid. And the pid changes each time the daemon is > restarted or the mount point expires and is then re-mounted. > If we could just monitor the pid spawned by auto.master I > think that would do it for us. I asked in another reply in > this thread if a daemon could be assigned a pid but don't > have a response yet. If it spawns a new process each time it mounts a new partition, would it not have a parent process that would at least be constant on the server? If that's the case, maybe you should just monitor the parent process. Otherwise, it would make sense to monitor a partition instead of a pid for a specific spawned process. James -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fffa2cacdb4d5c44a24b093011381218011a8...@ersbs2.eyereturn.local
RE: Monitoring AutoFS in SNMP
> > I am trying to find a MIB to monitor AutoFS but > everything I > > find is tied to the current pid AutoFS is running > under which > > of course changes each time it is restarted making it > useless > > as a monitoring metric. > > I'm not familiar with autofs but if you do a snmpwalk for > OID > .1.3.6.1.2.1.25.2.3.1, you will find a listing of all the > mounted > partitions, maybe instead of monitoring autofs, monitor the > existence of > a specific partition instead? I assume that's why you'd > want to monitor > autofs in the first place anyways. > > James > We are using autofs to mount cdrom and dvd iso images. There are nearly 100 of them. Too many to really monitor individually so we wanted to just monitor autofs. It looks to me like each auto.* file in /etc spawns it's own process and pid. And the pid changes each time the daemon is restarted or the mount point expires and is then re-mounted. If we could just monitor the pid spawned by auto.master I think that would do it for us. I asked in another reply in this thread if a daemon could be assigned a pid but don't have a response yet. Thanks, Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/191038.55257...@web33808.mail.mud.yahoo.com
Re: Monitoring AutoFS in SNMP
> > I am trying to find a MIB to monitor AutoFS but > everything I find > > is tied to the current pid AutoFS is running under > which of > > course changes each time it is restarted making it > useless as a > > monitoring metric. > > ??? Isn't that a *good* thing? > > I'd look at the "restart" section of the autofs startup > script to see if there's a way to "regenerate" the MIB when > you restart autofs. > > Maybe, though, that's too hackish. > I am sure it is a *good* thing security wise but it seems to be hampering usability at the moment. I don't think you can rewrite a MIB on the fly. I am no expert but I think they are written as products are developed then distributed as a support service. I am curious though, it there a way to force a daemon to take a specific pid at startup? Thanks, Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/71641.50758...@web33808.mail.mud.yahoo.com
RE: Monitoring AutoFS in SNMP
> I am trying to find a MIB to monitor AutoFS but everything I > find is tied to the current pid AutoFS is running under which > of course changes each time it is restarted making it useless > as a monitoring metric. I'm not familiar with autofs but if you do a snmpwalk for OID .1.3.6.1.2.1.25.2.3.1, you will find a listing of all the mounted partitions, maybe instead of monitoring autofs, monitor the existence of a specific partition instead? I assume that's why you'd want to monitor autofs in the first place anyways. James -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fffa2cacdb4d5c44a24b093011381218011a8...@ersbs2.eyereturn.local
Re: Monitoring AutoFS in SNMP
On 2010-03-23 09:00, Brian wrote: I am trying to find a MIB to monitor AutoFS but everything I find is tied to the current pid AutoFS is running under which of > course changes each time it is restarted making it useless as a > monitoring metric. ??? Isn't that a *good* thing? I'd look at the "restart" section of the autofs startup script to see if there's a way to "regenerate" the MIB when you restart autofs. Maybe, though, that's too hackish. -- "History does not long entrust the care of freedom to the weak or the timid." Dwight Eisenhower -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ba8cdbf.7050...@cox.net
Monitoring AutoFS in SNMP
I am trying to find a MIB to monitor AutoFS but everything I find is tied to the current pid AutoFS is running under which of course changes each time it is restarted making it useless as a monitoring metric. Has anyone setup SNMP to monitor AutoFS or a similar type of daemon on a Debain system? Thanks, Brian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/590915.68384...@web33804.mail.mud.yahoo.com
Re: autofs stopped working on testing
Solved! On Sun, Jan 10, 2010 at 9:38 AM, Mike Castle wrote: > Oh ... I just remembered... / on the ldap server was full, and I ended > up nuking a lot of stuff on that partition. I wonder if I got overly > zealous and deleted something important. I hope not. Not sure if I deleted too much, or full partition caused problem, but I ended up restoring the slapd database from a backup, and that now everything appears to work again. I didn't suspect ldap at first, since auth was still working, and I didn't see anything obvious in any log files about DB corruption. Odd. Still, all seems to be working now. mrc -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
autofs stopped working on testing
Has anyone else noticed that autofs has stopped working on testing? I'm really just digging into the debugging process, so may not have read all of the necessary docs quite yet. I've had autofs working for /home and a /share hierarchy for quite some time now, and haven't had too many problems with it. But the initial set up was long enough ago that I don't exactly remember the details of setting it up. I've had one machine that's been giving me grief and had to reboot daily for the last several days, so I'm pretty sure that the cause is the last day or two. I'm not seeing any packages, however, that look like they might have caused the problem. Nothing like slapd, glibc, autofs, nss or the like. Oh ... I just remembered... / on the ldap server was full, and I ended up nuking a lot of stuff on that partition. I wonder if I got overly zealous and deleted something important. I hope not. Anyway, the symptom is that no autmount maps are being seen: /etc/init.d/autofs start no automount maps defined. Everything is saved in ldap, nothing in /etc ldapsearch -x still shows all of the pertinent information Still, any suggestions on how to proceed on this would be appreciated. mrc -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: usb automount disabled by installing/removing autofs
On 12.04.09 01:34, Stephen Guzik wrote: > Automounting used to work fine with gnome in squeeze. Then I > installed and removed autofs and now it seems to be disabled. Does > anyone know how to recover the original behaviour? automount mounts filesystems automatically when someone's trying to access the mount directory. for mounting USB driver there's usbmount which mounts them when they get connected. Check for that one -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
usb automount disabled by installing/removing autofs
Hi, Automounting used to work fine with gnome in squeeze. Then I installed and removed autofs and now it seems to be disabled. Does anyone know how to recover the original behaviour? Thanks, Stephen
naive question: autofs with negative niceness
Hello List, on my (little) cluster, I used autofs to mount the `/home' directory on the worker nodes: is it possible (and recommended) to give a negative niceness to automount ? what is the Debian to do so ? Thanks in advance, Jerome -- Jerome BENOIT jgmbenoit_at_mailsnare_dot_net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question concerning autofs, usbfs and vfat
Robert Cates wrote: Hi, and thanks for your help! I have not made any changes to the default configuration for autofs. The truth is, I'm not even sure I need it installed. I thought it sounded like a nice feature, but I haven't done anything with it yet. This machine is a server, so therefore no KDE or Gnome, or GUI at all. I'm using the USB data stick to backup data, and up to now I've been manually mounting with - mount -t auto /dev/sda1 /mnt/usb1 This is fine. A bit of extra work, but reliable and straightforward. ;) Once I've mounted, I'm able to tar and gzip, move the data files to the USB stick, and then umount with no apparent problem. It was not until a day or two later that I found out the machine was hosed. So, I doubt that the USB connections have anything to do with how your system got hosed. My autofs config files: /etc/auto.master # $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $ # # Sample auto.master file # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # For details of the format look at autofs(5). #/misc /etc/auto.misc --timeout=60 #/smb /etc/auto.smb #/misc /etc/auto.misc #/net /etc/auto.net /etc/auto.misc # $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $ # # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # Details may be found in the autofs(5) manpage cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom # the following entries are samples to pique your imagination #linux -ro,soft,intr ftp.example.org:/pub/linux #boot -fstype=ext2:/dev/hda1 #floppy -fstype=auto:/dev/fd0 #floppy -fstype=ext2:/dev/fd0 #e2floppy -fstype=ext2:/dev/fd0 #jaz-fstype=ext2:/dev/sdc1 #removable -fstype=ext2:/dev/hdd Nothing odd here, either. So long as all the lines in auto.master are commented, the daemon will start but basically do nothing. So, I don't understand why there would be any error message from autofs about improper configuration or bogus options. If you're not using it, you may want to remove it, just to be "safe". Or you can set it up to allow you to use the USB device (and CD/DVD, etc. if you like), so you don't need to do the mount/umount sequence. If this interests you, let me know and I'll provide details so you can set it up. My fstab looks like this: # /etc/fstab: static file system information. # # proc/proc procdefaults0 0 /dev/hda2 / ext3defaults,errors=remount-ro 0 1 /dev/hdd1 /data ext3defaults0 2 /dev/hdc1 /home ext3defaults,usrquota,grpquota 0 2 /dev/hda5 noneswapsw 0 0 /dev/hdb/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 /dev/sda1 /mnt/usb1 autorw,user,noauto 0 0 Nothing odd here. I did notice that your cdrom is /dev/hdb, so the above auto.misc would have problems (perhaps) since it wants /dev/cdrom as the device name (this assumes there is no symlink named /dev/cdrom that points to /dev/hdb). But this would not generate errors, given the way auto.master is written. FYI, using the type value of 'auto' will let you mount a usb device with either VFAT or NTFS filesystem types. If you know for a fact that the usb device is always a VFAT or NTFS, you can specifically name the type, vfat or ntfs in place of the word auto. Or, you could say 'vfat,ntfs' to limit the searching to just those two. And if you want to be able to write NTFS, you'll need the newer FUSE based tools (the ntfs-3g and libntfs-3g2 packages). Thanks again for your help! You're welcome, though I don't think I've been any help with the basic issue of being locked out from your system. ;( Robert -Original Message- From: Bob McGowan [mailto:[EMAIL PROTECTED] Sent: Dienstag, 5. Februar 2008 02:06 To: debian-user@lists.debian.org Subject: Re: question concerning autofs, usbfs and vfat Robert Cates wrote: Hi all, to get right straight to my question - i was wanting to know which is the proper file system to choose for a (normal) USB 2.0 data/flash stick - autofs, usbfs or maybe vfat? The stick is of course usable under Windows as well as linux (from kernel 2.4.x). I believe I need to set this in the fstab file, correct? I think there is some confusion as to the meaning of some of the fields in the mount command output, specifically the value for 'type'. The type 'vfat' is a real file system type, same as ext3 or xfs. For simplicit
RE: question concerning autofs, usbfs and vfat
Hi, and thanks for your help! I have not made any changes to the default configuration for autofs. The truth is, I'm not even sure I need it installed. I thought it sounded like a nice feature, but I haven't done anything with it yet. This machine is a server, so therefore no KDE or Gnome, or GUI at all. I'm using the USB data stick to backup data, and up to now I've been manually mounting with - mount -t auto /dev/sda1 /mnt/usb1 Once I've mounted, I'm able to tar and gzip, move the data files to the USB stick, and then umount with no apparent problem. It was not until a day or two later that I found out the machine was hosed. My autofs config files: /etc/auto.master # $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $ # # Sample auto.master file # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # For details of the format look at autofs(5). #/misc /etc/auto.misc --timeout=60 #/smb /etc/auto.smb #/misc /etc/auto.misc #/net /etc/auto.net /etc/auto.misc # $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $ # # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # Details may be found in the autofs(5) manpage cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom # the following entries are samples to pique your imagination #linux -ro,soft,intr ftp.example.org:/pub/linux #boot -fstype=ext2:/dev/hda1 #floppy -fstype=auto:/dev/fd0 #floppy -fstype=ext2:/dev/fd0 #e2floppy -fstype=ext2:/dev/fd0 #jaz-fstype=ext2:/dev/sdc1 #removable -fstype=ext2:/dev/hdd My fstab looks like this: # /etc/fstab: static file system information. # # proc/proc procdefaults0 0 /dev/hda2 / ext3defaults,errors=remount-ro 0 1 /dev/hdd1 /data ext3defaults0 2 /dev/hdc1 /home ext3defaults,usrquota,grpquota 0 2 /dev/hda5 noneswapsw 0 0 /dev/hdb/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 /dev/sda1 /mnt/usb1 autorw,user,noauto 0 0 Thanks again for your help! Robert -Original Message- From: Bob McGowan [mailto:[EMAIL PROTECTED] Sent: Dienstag, 5. Februar 2008 02:06 To: debian-user@lists.debian.org Subject: Re: question concerning autofs, usbfs and vfat Robert Cates wrote: > Hi all, > > > > to get right straight to my question - i was wanting to know which is > the proper file system to choose for a (normal) USB 2.0 data/flash > stick - autofs, usbfs or maybe vfat? The stick is of course usable > under Windows as well as linux (from kernel 2.4.x). I believe I need to > set this in the fstab file, correct? I think there is some confusion as to the meaning of some of the fields in the mount command output, specifically the value for 'type'. The type 'vfat' is a real file system type, same as ext3 or xfs. For simplicity, I will call the others 'pseudo' types, specific to some type of software that is running on the system. The "autofs" type is printed when the automount daemon is running, "usbfs" refers to the USB subsystem software. Though these "pseudo" types are printed by the mount command, they are only part of the picture. The rest of the picture is the actual file system type on the device in question (the USB stick, in your case). This may be VFAT or NTFS (which is becoming more common, particularly on larger devices like USB hard disks). To summarize: If you have automount installed and the configuration set up in /etc so it works, you would see something like this: automount(pid8835) on /var/autofs/misc type autofs \ (rw,fd=4,pgrp=8835,minproto=2,maxproto=4) in the mount out put. If you configured the auto.misc file for access to CD and DVD drives (as I have) and you had a cd in the drive and accessed the automount defined path (or a link to it), you would then also see, in the mount output, something like this: /dev/hdc on /var/autofs/misc/cd0 type iso9660 (ro,nosuid,nodev) Note that the type in this line is the actual file system type on the CD. > > > > My problem leading up to this question is - twice now in the past couple > of weeks I had my machine lockout access to various services, actually > pretty much all services, including mail (courier/postfix), web (apache > 2.2), SSH, DNS, just to name the main ones. This time I found something > odd - a message telling me that the autofs had a problem because of > bogus options. This lead me to believe the pr
Re: question concerning autofs, usbfs and vfat
Robert Cates wrote: Hi all, to get right straight to my question – i was wanting to know which is the proper file system to choose for a (normal) USB 2.0 data/flash stick – autofs, usbfs or maybe vfat? The stick is of course usable under Windows as well as linux (from kernel 2.4.x). I believe I need to set this in the fstab file, correct? I think there is some confusion as to the meaning of some of the fields in the mount command output, specifically the value for 'type'. The type 'vfat' is a real file system type, same as ext3 or xfs. For simplicity, I will call the others 'pseudo' types, specific to some type of software that is running on the system. The "autofs" type is printed when the automount daemon is running, "usbfs" refers to the USB subsystem software. Though these "pseudo" types are printed by the mount command, they are only part of the picture. The rest of the picture is the actual file system type on the device in question (the USB stick, in your case). This may be VFAT or NTFS (which is becoming more common, particularly on larger devices like USB hard disks). To summarize: If you have automount installed and the configuration set up in /etc so it works, you would see something like this: automount(pid8835) on /var/autofs/misc type autofs \ (rw,fd=4,pgrp=8835,minproto=2,maxproto=4) in the mount out put. If you configured the auto.misc file for access to CD and DVD drives (as I have) and you had a cd in the drive and accessed the automount defined path (or a link to it), you would then also see, in the mount output, something like this: /dev/hdc on /var/autofs/misc/cd0 type iso9660 (ro,nosuid,nodev) Note that the type in this line is the actual file system type on the CD. My problem leading up to this question is – twice now in the past couple of weeks I had my machine lockout access to various services, actually pretty much all services, including mail (courier/postfix), web (apache 2.2), SSH, DNS, just to name the main ones. This time I found something odd – a message telling me that the autofs had a problem because of bogus options. This lead me to believe the problem came from me mounting my USB 2.0 data stick which I use to backup data. After transferring the data, I umount the file system. The only other thing I’ve done prior to the last occurrence was that I updated the kernel to 2.6.18-6-686. So, have you configured automounter to do your USB mounting for you? Or, are you using default setup for USB devices as provided by KDE or GNOME? Or, do you mount it manually? Knowing the answer to this could help determine the cause of the error message from autofs, which may or may not be related to the hosed system issue. It may also help to see the content of the /etc/auto.* files. Any and all info/help on this matter will be greatly appreciated! Thanks in advance, Robert -- Bob McGowan smime.p7s Description: S/MIME Cryptographic Signature
question concerning autofs, usbfs and vfat
Hi all, to get right straight to my question - i was wanting to know which is the proper file system to choose for a (normal) USB 2.0 data/flash stick - autofs, usbfs or maybe vfat? The stick is of course usable under Windows as well as linux (from kernel 2.4.x). I believe I need to set this in the fstab file, correct? My problem leading up to this question is - twice now in the past couple of weeks I had my machine lockout access to various services, actually pretty much all services, including mail (courier/postfix), web (apache 2.2), SSH, DNS, just to name the main ones. This time I found something odd - a message telling me that the autofs had a problem because of bogus options. This lead me to believe the problem came from me mounting my USB 2.0 data stick which I use to backup data. After transferring the data, I umount the file system. The only other thing I've done prior to the last occurrence was that I updated the kernel to 2.6.18-6-686. Any and all info/help on this matter will be greatly appreciated! Thanks in advance, Robert
Re: Autofs configuration
Bruno Cochofel wrote: Hi, I have this config of autofs: # auto.master /var/autofs/removable /etc/auto.removable --timeout=2 /var/autofs/nfs /etc/auto.misc --timeout=60 # auto.removable # devices cdrom -fstype=iso9660,ro,sync,nodev,nosuid :/dev/cdrom floppy -fstype=auto,sync,nodev,nosuid :/dev/fd0 # usb pen usbdrive-fstype=vfat,rw,gid=100,umask=002 :/dev/sda1 # card readers cfdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sda1 msdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sdb1 sddrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sdc1 smdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sdd1 But whenever I try to access the dirs I get this on /var/log/syslog: # /var/log/syslog Jan 27 12:53:51 debian automount[9543]: lookup(program): lookup for usbdrive failed Jan 27 12:53:51 debian automount[9543]: failed to mount /var/autofs/removable/usbdrive Jan 27 12:53:51 debian automount[9545]: lookup(program): lookup for usbdrive failed Jan 27 12:53:51 debian automount[9545]: failed to mount /var/autofs/removable/usbdrive Jan 27 12:53:51 debian automount[9547]: lookup(program): lookup for usbdrive failed Jan 27 12:53:51 debian automount[9547]: failed to mount /var/autofs/removable/usbdrive I can mount the nfs drives but none of the usb. How can I do this? The sda* are taken from dmesg -- Cumprimentos, Bruno Cochofel, tlm: +351 912055880 ICQ: 309147167 MSN: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Skype: bcochofel Two things I can think of to check, that caused me headaches: 1. It seems autofs is very picky about the type of white space used to separate the fields. It wants tabs, not spaces. 2. The USB drives may actually be ending up somewhere else. That is to say, maybe you got sdb the first time, when you checked with dmsg, but got sda or sdc the next time you plugged the USB device, because there was something else found before it. I solved this by setting up to use label based mounting. Add a unique label to your USB drive file system (mlabel, e2label, ...), for example USBDRV. Set up auto.removable to look like this: usbdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/disk/by-label/USBDRV The label, USBDRV is a link to the actual device node, as assigned by the system. -- Bob McGowan smime.p7s Description: S/MIME Cryptographic Signature
Autofs configuration
Hi, I have this config of autofs: # auto.master /var/autofs/removable /etc/auto.removable --timeout=2 /var/autofs/nfs /etc/auto.misc --timeout=60 # auto.removable # devices cdrom -fstype=iso9660,ro,sync,nodev,nosuid :/dev/cdrom floppy -fstype=auto,sync,nodev,nosuid :/dev/fd0 # usb pen usbdrive-fstype=vfat,rw,gid=100,umask=002 :/dev/sda1 # card readers cfdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sda1 msdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sdb1 sddrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sdc1 smdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sdd1 But whenever I try to access the dirs I get this on /var/log/syslog: # /var/log/syslog Jan 27 12:53:51 debian automount[9543]: lookup(program): lookup for usbdrive failed Jan 27 12:53:51 debian automount[9543]: failed to mount /var/autofs/removable/usbdrive Jan 27 12:53:51 debian automount[9545]: lookup(program): lookup for usbdrive failed Jan 27 12:53:51 debian automount[9545]: failed to mount /var/autofs/removable/usbdrive Jan 27 12:53:51 debian automount[9547]: lookup(program): lookup for usbdrive failed Jan 27 12:53:51 debian automount[9547]: failed to mount /var/autofs/removable/usbdrive I can mount the nfs drives but none of the usb. How can I do this? The sda* are taken from dmesg -- Cumprimentos, Bruno Cochofel, tlm: +351 912055880 ICQ: 309147167 MSN: [EMAIL PROTECTED] Skype: bcochofel
Re: autofs+ldap (without /etc/auto.master)
Hi Martin, the initscript is unable to find your auto.master map. Unless you've modified the initscript, it expects an object of class automountMap with ou=auto.master _below_ LDAPBASE. Have a look at ] /usr/share/doc/autofs-ldap/README.ldap_master for an example. Regards, Jan signature.asc Description: Digital signature
Re: autofs+ldap (without /etc/auto.master)
On Thu, May 10, 2007 at 06:16:08PM +0200, Martin Marcher wrote: > Hello, > > i'm trying to get autofs pull everything from ldap (even auto.master) > > Now the situation is the following having an auto.master as below and > nsswitch.conf with !automount: files" pulls the map from ldap (because > auto.master says to...), but nsswitch.conf with "automount: ldap" > doesn't do anything. Although the initscript tries to parse wether we > use file or ldap (the default etch initscript, just trying to > investigate) > > I atteched the info i have below, unfortunately the log stays quite > upon restarting the auomount daemon even though i set -d -v for the > daemonopts... > Did you try setting the debug_level for slapd to see if the requests are evey being made to the LDAP server? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
autofs+ldap (without /etc/auto.master)
Hello, i'm trying to get autofs pull everything from ldap (even auto.master) Now the situation is the following having an auto.master as below and nsswitch.conf with !automount: files" pulls the map from ldap (because auto.master says to...), but nsswitch.conf with "automount: ldap" doesn't do anything. Although the initscript tries to parse wether we use file or ldap (the default etch initscript, just trying to investigate) I atteched the info i have below, unfortunately the log stays quite upon restarting the auomount daemon even though i set -d -v for the daemonopts... # /etc/init.d/autofs restart Stopping automounter: done. Starting automounter: no automount maps defined. auto.master: (if used) /data ldap:backend.example.com:ou=autofs,dc=example,dc=com nsswitch.conf: automount:ldap /etc/default/autofs: TIMEOUT=300 DISABLE_DIRECT=0 LDAPURI=ldap://backend.example.com/ LDAPBASE=ou=autofs,dc=example,dc=com the ldap entries: dn: ou=autofs,dc=example,dc=com objectClass: automountMap objectClass: top ou: autofs dn: ou=data,ou=autofs,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: data dn: cn=/data,ou=autofs,dc=example,dc=com objectClass: automount objectClass: top automountinformation: ldap:backend.example.com:ou=data,ou=autofs,dc=exampl e,dc=com cn: /data dn: cn=management,ou=data,ou=autofs,dc=example,dc=com objectClass: automount objectClass: top automountinformation: -fstype=nfs,hard,intr,rsize=8192,wsize=8192 shares:/sr v/nfs/management cn: management dn: cn=example,ou=data,ou=autofs,dc=example,dc=com objectClass: automount objectClass: top automountinformation: -fstype=nfs,hard,intr,rsize=8192,wsize=8192 shares:/sr v/nfs/example cn: example -- Martin Marcher [EMAIL PROTECTED] http://www.mycorners.com https://www.xing.com/profile/Martin_Marcher http://www.linkedin.com/in/martinmarcher http://www.studivz.net/profile.php?ids=9f83ea8c5996b8ec http://www.amazon.de/gp/registry/wishlist/3KDAGCL2NKOIM/ref=reg_hu-wl_goto-registry/302-4432803-5146435?ie=UTF8&sort=date-added -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autofs and /home/home
Hi, > I can't seem to figure out a *very* simple automount configuration > (I've done this before, but it was over two years ago :-( ). > > After much work (and not enough understanding!), I have succeed in > automounting a remote /home directory on a local client using > 'autofs'. > > Unfortunately, the mounted directory on the client is under /home/home > instead of /home. usually automount is used like this: * you create a dedicated directory where all your automounted directories shall live, e.g. /net, and tell the master map about it ] (/etc/auto.master) ] /net /etc/auto.net * you create that map specifying where each possible subdirectory should be mounted from upon request, e.g. ] (/etc/auto.net) ] share -fstype=nfs server1:/srv/share resulting in a working automounted share ] /net/share <-> server1:/srv/share. This map (auto.net) is called "indirect". If you want to have /home itself automounted, you won't get anywhere with indirect maps, because that would mean that / had to be governed by an automount daemon. Have a look at /usr/share/doc/autofs/README.direct and pay attention to the warnings at the bottom of it. When everything is set up, don't forget to edit /etc/default/autofs in order to switch off DISABLE_DIRECT. Regards, Jan signature.asc Description: Digital signature
Re: autofs and /home/home
Hi, In your config, /etc/auto.master: /home /etc/auto.misc --timeout 60 This should be fine ... /etc/auto.misc: home-fstype=nfs,hard,intr 1.2.3.4:/home But, this line should be * -fstype=nfs,hard,intr 1.2.3.4:/home/& I've a similar setup and it's working just fine. -- - Shashishekhar S Consultant - Debian GNU/Linux Remote Administration, Deployments Mail Services, Tips and Tricks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autofs and /home/home
Couldn't you just edit the /etc/fstab? Maybe I'm missing something but if you put an entry for your device in the /etc/fstab it should automatically mount it and put it in the right folder. On Sun, 18 Feb 2007 12:10:43 -0500 Kenneth Jacker <[EMAIL PROTECTED]> wrote: > Config: Debian/etch > > I can't seem to figure out a *very* simple automount configuration > (I've done this before, but it was over two years ago :-( ). > > After much work (and not enough understanding!), I have succeed in > automounting a remote /home directory on a local client using > 'autofs'. > > Unfortunately, the mounted directory on the client is under /home/home > instead of /home. > > Here are the two key lines on the client: > > /etc/auto.master: > /home /etc/auto.misc --timeout 60 > > /etc/auto.misc: > home-fstype=nfs,hard,intr 1.2.3.4:/home > > > Can someone help me to have the remote /home on the server show up as > just /home on the client? > > Any other suggestions and/or comments are most welcomed ... > > Thanks! > -- > Prof Kenneth H Jacker [EMAIL PROTECTED] > Computer Science Dept www.cs.appstate.edu/~khj > Appalachian State Univ > Boone, NC 28608 USA > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
autofs and /home/home
Config: Debian/etch I can't seem to figure out a *very* simple automount configuration (I've done this before, but it was over two years ago :-( ). After much work (and not enough understanding!), I have succeed in automounting a remote /home directory on a local client using 'autofs'. Unfortunately, the mounted directory on the client is under /home/home instead of /home. Here are the two key lines on the client: /etc/auto.master: /home /etc/auto.misc --timeout 60 /etc/auto.misc: home-fstype=nfs,hard,intr 1.2.3.4:/home Can someone help me to have the remote /home on the server show up as just /home on the client? Any other suggestions and/or comments are most welcomed ... Thanks! -- Prof Kenneth H Jacker [EMAIL PROTECTED] Computer Science Dept www.cs.appstate.edu/~khj Appalachian State Univ Boone, NC 28608 USA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SOLVED: Autofs behaviour: how to show mountable resources in advance
Dieter Roels wrote: Joao Carlos de Lima Roscoe wrote: I have a bunch of autofs mounts in my etch box, whose doesn't show in my filesystem tree until I explicitly use them, with a cd command, for instance (ok, this is the intend autofs behaviour); My Solaris 9 boxes show a different behaviour: autofs resources do show in the filesystem tree while still not mounted, as owned by root. Once I effectively use them, they are mounted, and show with correct group/owner. That may look odd, since mounts are performed only when needed, but is convenient for the user, because he/her can see in advance the resources he/her can reach. Is there any way to get such behaviour with debian etch? Autofs should create the dirs if you add --ghost behind the entry in /etc/auto.master like this: /foo/etc/auto.foo--ghost -D That's *really* great! Worked as a bliss. Thank you very much, Joao -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Autofs behaviour: how to show mountable resources in advance
Joao Carlos de Lima Roscoe wrote: I have a bunch of autofs mounts in my etch box, whose doesn't show in my filesystem tree until I explicitly use them, with a cd command, for instance (ok, this is the intend autofs behaviour); My Solaris 9 boxes show a different behaviour: autofs resources do show in the filesystem tree while still not mounted, as owned by root. Once I effectively use them, they are mounted, and show with correct group/owner. That may look odd, since mounts are performed only when needed, but is convenient for the user, because he/her can see in advance the resources he/her can reach. Is there any way to get such behaviour with debian etch? Autofs should create the dirs if you add --ghost behind the entry in /etc/auto.master like this: /foo/etc/auto.foo --ghost -D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Autofs behaviour: how to show mountable resources in advance
I have a bunch of autofs mounts in my etch box, whose doesn't show in my filesystem tree until I explicitly use them, with a cd command, for instance (ok, this is the intend autofs behaviour); My Solaris 9 boxes show a different behaviour: autofs resources do show in the filesystem tree while still not mounted, as owned by root. Once I effectively use them, they are mounted, and show with correct group/owner. That may look odd, since mounts are performed only when needed, but is convenient for the user, because he/her can see in advance the resources he/her can reach. Is there any way to get such behaviour with debian etch? Thanks, Joao -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autofs only mounting one fs at a time.
On 08.07.06 08:48, wehn wrote: > Ah, updating to unstable seems to have resolved the- only one device at > a time problems. > > And the multiple partition thing is working now that I found out > "-fstype=auto,sync,rw,uid=1000,gid=100" doesn't play nicely with my 2nd > ext3 partition (1st is vfat): > > dmesg: > EXT3-fs: Unrecognized mount option "uid=1000" or missing value > EXT3-fs: Unrecognized mount option "gid=100" or missing value > > This could take some tweaking to get right. add "quiet" to mount options. it will suppress error messages about unknown mount options, which happens often for devices which can have more fvilesystems, like USB storages. > >Which is what I am doing, maybe I wasn't clear enough: > >1st device inserted is accessible if accessed eg opening photos from the > >gimp. 2nd is not accessible (from a different program) until the first > >is removed. Aha, i didn't get it before. Maybe i have had read it once more. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. He who laughs last thinks slowest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autofs only mounting one fs at a time.
Ah, updating to unstable seems to have resolved the- only one device at a time problems. And the multiple partition thing is working now that I found out "-fstype=auto,sync,rw,uid=1000,gid=100" doesn't play nicely with my 2nd ext3 partition (1st is vfat): dmesg: EXT3-fs: Unrecognized mount option "uid=1000" or missing value EXT3-fs: Unrecognized mount option "gid=100" or missing value This could take some tweaking to get right. wehn wrote: >On 06.07.06 13:41, wehn wrote: >> I set up autofs for automounting with help of: >> http://greenfly.net/tips/autofs.html >> >> But I can only mount the 1st parition of the first device I insert. >>Does anyone know what is wrong? > >the idea of using autofs for this purpose :) > >autofs is system that allows you automatically mount a directory if you >try >to access it. So, autofs only mounts directories if you change them or >try >to open them. Which is what I am doing, maybe I wasn't clear enough: 1st device inserted is accessible if accessed eg opening photos from the gimp. 2nd is not accessible (from a different program) until the first is removed. I'd love to get this working, since it seems to be a great way of doing things. No more 'ejecting' usb drives. > >> If I insert a USB drive, it mounts /dev/sda1 and is accessable from >> /media/sda1. Insert a second drive and it isn't accessable until the >> first is pulled out. Then it works fine from /media/sdb1. Similar >> problem with multiple partitions, only the first is mountable with >> autofs, others don't work. > >use "udev" package for automatic mounting of usb drives. I'll have a look and see if it's a good alternative while I try and fix this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autofs only mounting one fs at a time.
>On 06.07.06 13:41, wehn wrote: >> I set up autofs for automounting with help of: >> http://greenfly.net/tips/autofs.html >> >> But I can only mount the 1st parition of the first device I insert. >>Does anyone know what is wrong? > >the idea of using autofs for this purpose :) > >autofs is system that allows you automatically mount a directory if you >try >to access it. So, autofs only mounts directories if you change them or >try >to open them. Which is what I am doing, maybe I wasn't clear enough: 1st device inserted is accessible if accessed eg opening photos from the gimp. 2nd is not accessible (from a different program) until the first is removed. I'd love to get this working, since it seems to be a great way of doing things. No more 'ejecting' usb drives. > >> If I insert a USB drive, it mounts /dev/sda1 and is accessable from >> /media/sda1. Insert a second drive and it isn't accessable until the >> first is pulled out. Then it works fine from /media/sdb1. Similar >> problem with multiple partitions, only the first is mountable with >> autofs, others don't work. > >use "udev" package for automatic mounting of usb drives. I'll have a look and see if it's a good alternative while I try and fix this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autofs only mounting one fs at a time.
On Thu, Jul 06, 2006 at 02:53:09PM +1000, wehn wrote: > Tony Heal wrote: > >Did you try duplicating the line in auto.removable with a second mount > >point? > > > > Yes. Here's my auto.removable: > > cdrom -fstype=iso9660,ro,sync,nodev,nosuid:/dev/cdrom > floppy -fstype=auto,sync,nodev,nosuid :/dev/fd0 > sda1 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sda1 > sda2 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sda2 > sda3 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sda3 > sdb1 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sdb1 > sdb2 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sdb2 > sdb3 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sdb3 > > how about your auto.master as well? signature.asc Description: Digital signature
Re: autofs only mounting one fs at a time.
On 06.07.06 13:41, wehn wrote: > I set up autofs for automounting with help of: > http://greenfly.net/tips/autofs.html > > But I can only mount the 1st parition of the first device I insert. Does > anyone know what is wrong? the idea of using autofs for this purpose :) autofs is system that allows you automatically mount a directory if you try to access it. So, autofs only mounts directories if you change them or try to open them. > If I insert a USB drive, it mounts /dev/sda1 and is accessable from > /media/sda1. Insert a second drive and it isn't accessable until the > first is pulled out. Then it works fine from /media/sdb1. Similar > problem with multiple partitions, only the first is mountable with > autofs, others don't work. use "udev" package for automatic mounting of usb drives. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. REALITY.SYS corrupted. Press any key to reboot Universe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autofs only mounting one fs at a time.
Tony Heal wrote: Did you try duplicating the line in auto.removable with a second mount point? Yes. Here's my auto.removable: cdrom -fstype=iso9660,ro,sync,nodev,nosuid:/dev/cdrom floppy -fstype=auto,sync,nodev,nosuid :/dev/fd0 sda1 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sda1 sda2 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sda2 sda3 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sda3 sdb1 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sdb1 sdb2 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sdb2 sdb3 -fstype=auto,sync,rw,uid=1000,gid=100:/dev/sdb3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: autofs only mounting one fs at a time.
Did you try duplicating the line in auto.removable with a second mount point? Tony Heal Pace Systems Group, Inc. 800-624-5999 [EMAIL PROTECTED] -Original Message- From: wehn [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 11:41 PM To: debian-user@lists.debian.org Subject: autofs only mounting one fs at a time. I set up autofs for automounting with help of: http://greenfly.net/tips/autofs.html But I can only mount the 1st parition of the first device I insert. Does anyone know what is wrong? If I insert a USB drive, it mounts /dev/sda1 and is accessable from /media/sda1. Insert a second drive and it isn't accessable until the first is pulled out. Then it works fine from /media/sdb1. Similar problem with multiple partitions, only the first is mountable with autofs, others don't work. Is it that the "automount(pid3488) on /var/autofs/removable type autofs (rw,fd=4,pgrp=3488,minproto=2,maxproto=4)" process can only can only handle one mount at a time? cheers, wehn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
