Tag Info

Hot answers tagged

4

On Ubuntu 10.04, both autofs and GDM are Upstart (/etc/init) jobs, which means that they can potentially run in parallel. However, since neither has an explicit dependency on the other, there is nothing enforcing that GDM starts after autofs, so there is a race condition between the two. The best way to solve this is to reconfigure GDM to only start once ...


4

There should be an /etc/auto.smb already, use that, and add the following line to /etc/auto.master: /cifs /etc/auto.smb --timeout=60 Now all cifs shares will show up under /cifs: ls /cifs/<server> will show all the shares available. You might want to put some options in /etc/auto.smb to mount with specific modes. I have a auto.smb that I ...


3

Warning: Ugly hack ahead! The best thing will of course be to change the data in the LDAP server, and save your self the trouble, but here it goes: Add the following line at the end of /etc/security/pam_env.conf: HOME DEFAULT="/home/@{PAM_USER}" This will override the users $HOME variable to point to the right directory. However, this is only ...


3

Is there a way to make autofs mount stuff as the current user? Not really, but what you could do is setup a group for users who will be allowed to have access to that resource, add all the users to the group, and then finally pass the gid, umask, and dmask options to set the group, and permissions the fat filesystem will use once it is mounted.


3

I think you have a cart before the horse problem here in that when you export a file system using NFS it locks on to the source direcotory. You are trying to not even have that source directory available at that time and only put something there via a mount later. This will not work, because once you give NFS a handle on something to share, it will always ...


3

lookup(program) means automount thinks your map is an executable, does it have the executable bit set? lookup(file) is what you should be seeing See http://www.squarebox.co.uk/cgi-squarebox/manServer/automount.8.


3

Edit: the rest of my answer is mostly off-topic. You're doing it the right way, but the feature was only introduced in autofs 5.0.6. From the git repository: Author: Ian Kent Date: Fri May 25 12:28:56 2012 +0800 autofs-5.0.6 - move timeout to map_source Move the map entry timeout field from "struct autofs_point" to "struct map_source". The result ...


2

this turned out to be the clue: rpc.idmapd[5924]: nfsdcb: id '-2' too big! the issue was that the default nfsnobody user has a uid of 4294967294 , but on a 64-bit CentOS system it appears to be interpreting this number in a 32-bit context leading to the infamous -2. The fix is to : change nfsnobody user/group to uid/gid 65534 on both client and server ...


2

Yes; give automount the "--ghost" flag. Don't know offhand where that's configured in Debian-esque init files. Aha. Edit /etc/default/autofs to contain the line: DAEMONOPTIONS=--ghost I believe that's right.


2

A Windows Server OS on a reasonable modern server computer will handle 60 simultaneous connections to a share with no headaches whatsoever. I've had well over 300 simultaneous connections from Windows clients to the same share on a Windows Server with absolutely no problems (on vintage 2004 hardware). I can't tell you what the per-client encumbrance to ...


2

There are 2 approaches to this kind of setup: You have a shared home directory over nfs. In which case you use the AutoFS method to mount the home dir on access under /home (like you did with putting /home in auto.master) You have no shared home, and want a homedir for the user on each server he logins to. In this case you need pam_mkhomedir to create the ...


2

I just did this on a CentOS 5.6 box and I think part of your problem might be with your auto.test file. In it's current form you'll be creating a /test mount point and then a single moung of test under it, i.e. /test/test. Also you might want to add the --ghost switch to your auto.master line like so: /test /etc/auto.test --timeout=60 --ghost The ...


2

change server-ip -fstype=cifs,rw,noperm,user=DOMAIN\username,pass=password ://server-ip/share to share -fstype=cifs,rw,noperm,user=username,pass=password,domain=domain ://server-ip/share


2

Well, I got it myself. The documentation about it is quite lacking in Red Hat, but we do have Arch Wiki :-) So, Adding the flag --ghost to specific maps will show them. Now my setting look like this: # cat /etc/sysconfig/autofs # # BROWSE_MODE="no" #EOF # cat /etc/auto.master /home /etc/auto.home /shared auto.share ...


2

I believe that specified files (EX: .profile and .cshrc) from /etc/skel are only copied when you invoke the newuser (or equivalent command) to create a new user. Aside from that it is not used.


2

Currently the work-around I'm using, is to add an extra event (starting autofs) on the "start on" line in /etc/init/statd.conf: start on (started portmap or mounting TYPE=nfs or starting autofs) This makes upstart start statd before autofs is started.


2

Try umount -a -t autofs. This will umount every autofs mount.


2

I suppose the credentials file will be read by mount.cifs, like for other CIFS mounts. So I had a look at the mount.cifs.c source file in the current cifs-utils code, which should be for version 6.3. The code for reading the password does no unescaping, except that every comma is doubled in the password field of the parsed_mount_info struct, as is apparently ...


2

It's actually hard to argue one way or the other. The only item I can point out (happened to me) is that if you are using static mounts as in fstab and someone/thing makes an error the system may not boot and you'll have to go into rescue mode to get the system back online. That won't happen when using autofs.


1

You are using NFS version 4 (nfs4) which exports a single pseudo-filesystem rather than lots of separate filesystems. This is specified on the NFS server in /etc/exports by fsid=0, and in your case is called /export (although it could be called anything). That is why you cannot remove that line or comment it out. On the NFS client, this parent (in your ...


1

I had the same problem. In my case, encrypted data container at /home/.mysql was owned by root:root. It was mounted with mysql uid and gid, so technically, owner of mounted directory was mysql user, but behind it was encrypted container owned by root. That's why encfs complained about permission denied.


1

The purpose of the automounter, is basically to only mount things when needed. If the maps are correct all the user would have to do is to cd to the area and it will automatically mount. Once not needed (no users needing the mount after a specified period of time), it will unmount the disk. The same would happen for the /home area as well if the login ...


1

Have you tried adding ",user" after the "rw" in auto.misc?


1

I would guess that maybe you aren't escaping your credentials correctly in the file. The \ in the username may be breaking things. I use a credentials file, I believe it is much safer. This are the files I use to auto-mount a particular share. /etc/auto.master /.autofs/cifssrvername /etc/auto.cifssrvername --timeout=600 /etc/auto.cifssrvername share ...


1

What distribution or kernel version are you running? I don't see anything consistent, but at least some manual pages I see indicate that the wildcard map is not ghosted. This behavior makes some intuitive sense; the wildcard means that any valid pathname is a candidate for mounting, and so the client can't realistically present a choice of mount points ...


1

Since I just spent my entire morning debugging this same issue. Let me explain what happened above. /etc/auto.master ## Mount this test share: /test /etc/auto.test --timeout=60 This means I want to mount something at /test and for the details read /etc/auto.test /etc/auto.test test ...


1

Are you getting anything in the logs?


1

In /etc/sysconfig/autofs, change the MOUNT_NFS_DEFAULT_PROTOCOL variable. # MOUNT_NFS_DEFAULT_PROTOCOL - specify the default protocol used by # mount.nfs(8). Since we can't identify # the default automatically we need to # set it in our configuration. This will # ...


1

Yes, attributes such as uid are cached by the NFS client. On Solaris & OpenSolaris the options to control how long they're cached are documented in the mount_nfs(1m) man page - see the option names starting with ac like actimeo and the later man page sections they reference, such as File Attributes and Specifying Values for Attribute Cache Duration ...


1

Looks like the vanilla install of CentOS 5.1 has a known kernel bug that is causing this issue: http://bugs.centos.org/view.php?id=2448 It was fixed some time ago, and upgrading to the latest 5.1 kernel fixed the issue.



Only top voted, non community-wiki answers of a minimum length are eligible