Nice post! Do you know how to remove the password from the file? I have a link to another thread that uses C code. It would be nice if Lion had something built-in.
Unfortunately I do not, mount_afp doesn't support a -o credetials=/some/file/some/where like mount_cifs does so you can't put that into the auto_afp file.
That best protection for this setup is the chmod 600 on the file so only your admins can read it. Unfortunately if everyone is an admin, eh not so good.
Thanks for the tips, I've tried all of these before, and just tried it again, still, they end up mounted as root.
The mountpoint's folder perms show as (no matter what I do before or after mounting):
dr-xr-xr-x 2 root wheel 1 Dec 2 21:51 files-3
When I simply type "mount", that mount shows as:
map auto_afp on /Volumes/NAS/files-3 (autofs, nosuid, automounted, nobrowse)
Where other shares that I mount using "mount_afp" will add to this to the end of the ( ) area: "mounted by user"
I've tried changing the mount point to my a folder inside my home folder, it's stll mounted as root and chowned to root. I've tried chowning the auto_afp and auto_master to user:wheel, nothing seems to change it.
I'm bummed, becuase CLEARLY something changed in Lion, this ALL worked PERFECTLY and it was awesome to have on demand mounts (specially for the laptop when I would leave the NAS at home and come back)
Unfortunatley I've had to resort to a stupid script that I will run that runs mount_afp commands which properly mounts the share as my user, I've also added some options to make it more "sticky" (ie it takes longer to time out) but again, it's FAR from perfect like autofs was.
Okay I just had to reboot my MacMini system because of trying to get something else fixed and found that my mount point didn't come back up with user permissions (root only). So I did the following.
- Removed entry from /etc/auto_afp
- Restarted autofs (automount -vc)
- Removed the mount point in /Volumes
- Readded entry to /etc/auto_afp
- Restart autofs
- Checked Share and had access
My mount point is /Volumes/Media and when I removed if from autofs and restarted autofs the mount point was left behind with incorrect permissions. I removed it and DID NOT recreate it before restarting autofs again. This seemed to have fixed the permissions issues. However, this did not survive a test reboot of the system, so it looks like maybe when autofs is shutting down it doesn't remove the mount point?
I've been having this problem as well on Lion. Snow Leo worked fine, exact same configuration. Even if I remove the mountpoints, they get re-created properly, however, they are mounted with root permissions. It's really bizzare. I expect Apple did something in the name of security, that broke the only use case I can see for the autofs daemon......
I wonder if we can replace it with a compiled from source version from BSD or something.....
Damnit Apple. NFS works till you try to use it, then you get disconnect errors. The only conclusion I have at this point is that autofs is totally broken in Lion and is useless. On the box I really need this functionality I'll probably have to revert to snow leopard as it worked perfectly there and the changes is Lion don't matter to me on that machine. Drives mounted directly via cmd-K work fine, so it has to be autofs, not the network/sharing stack or the server side.
Hacks like using login items are not sufficient for everyone. The biggest problem is that they don't auto-reconnect if the server reboots or the network disconnects etc.. IMO this is a really basic function of any Unix based OS these days and having it so broken is a huge failure in QA. If they don't want to support the normal autofs daemon, then they should completely remove it and move the functionality to the GUI. In this day and age of pervasive home networks, there is no excuse for not having the equivalant of the stupid automount checkbox that Windows has had since Win95. Ideally, they would fix autofs and provide a simple UI for it like that checkbox in Windows when mounting a drive.
Apologies if someone already said this.
I was having this problem too. Here are the bad permissions on the mountpoint:
[bwood@ucbmbp ~]$ sudo ls -ld /Users/bwood/share
dr-xr-xr-x 2 root wheel 1 Dec 21 23:38 /Users/bwood/share
I resolved the root ownership of mountpoint on 10.7 like this:
1. as normal user create the mountpoint directory: mkdir ~/Linkstation
2. make the needed edits to /etc/auto_master and (in my case) /etc/auto_smb. My auto_smb contains
/Users/bwood/Linkstation -fstype=smbfs ://admin:PASSWORD@192.168.0.160/share
3. sudo automount -vc
[bwood@ucbmbp ~]$ sudo ls -ld /Users/bwood/Linkstation/
drwx------ 1 bwood wheel 16384 Nov 27 20:46 /Users/bwood/Linkstation/
[bwood@ucbmbp ~]$ ls Linkstation/
caroline monk trashbox voutcity
I tried creating the directories for mount points as a normal user. The autofs daemon would change the permissions for me....
I got NFS working properly. Added "locallocks" to the mount options. Here's a sample line:
Travis -rw,rwsize=1048576,vers=3,noatime,intr,soft,locallocks 10.1.0.2:/raid/Travis
Now the mounts work properly and don't disconnect constantly. I never did get SMB reliably working.
Looks like mine with "noowner" are working:
in /etc/fstab I have
192.168.89.105:/music /Users/Deborah/Shares/music url automounted,noowners,url==cifs://(username):(password)@192.168.89.105/music 0 0
and /etc/automaster has
+auto_master # Use directory service /net -hosts -nobrowse,hidefromfinder,nosuid /home auto_home -nobrowse,hidefromfinder /Network/Servers -fstab /- -static
I had to remove the entries from fstab, issue a sudo automount -vc to remove the mounts, then manually create the mount point at /Users/Deborah/Shares/music using mkdir music, then sudo chown Deborah:staff /Users/Deborah/Shares/music, then put the entries back in fstab, and do another sudo automount -vc to mount them again.
It's too early to say for sure whether this will last any length of time.
In Snow Leopard I didn't have the noowners option, and it worked fine. Must have broken when upgrading to Lion. With noowners, everything in the share is owned by the current user, which is fine for me since I don't rely on the user permissions within my NAS.