Hi!
Thanks to some of you I got autofs set up on my C7 netbook for mounting local cifs filesytems.
Now I want to do something on my C7 desktop machine, that seems to me to be a little different, and I"m not sure how to do it.
I have an external RAID1 box that attaches via USB. It is/will be nearly always /dev/sdc, but being USB I can't guarantee that it will always be found there.
accordingly, in my /etc/fstab I have an entry that mounts it via its UUID:
UUID=09bfc97a-8db2-46de-b4dd-427da19b114 /mnt/backup xfs defaults,noauto,users 0 2
and I'm wondering how to specify that in an autofs recipe instead...
If doing cifs mounts, /etc/auto.master may contain this line:
/mymount /etc/auto.mymount
then there would be a file /etc/auto.mymount that contains a line similar to this:
winbox -fstype=cifs,rw,noperm,user=sushi,pass=yummy ://winbox/getme
so, in my case, the USB drive contains an xfs filesystem. would I do something like this:
in /etc/auto.master:
backup /etc/auto.backup
and in /etc/auto.backup
backup -fstype=xfs,defaults,noauto,users :UUID=09bfc97a-8db2-46de-b4dd-427da19b114
Would that be expected to work, or am I all overlooking something obvious?
Thanks in advance for your advice!
Fred
On 08/21/2017 07:23 PM, Fred Smith wrote:
so, in my case, the USB drive contains an xfs filesystem. would I do something like this:
in /etc/auto.master: backup /etc/auto.backup
and in /etc/auto.backup backup -fstype=xfs,defaults,noauto,users :UUID=09bfc97a-8db2-46de-b4dd-427da19b114
In auto.master, the first field is a directory, so it should be "/backup".
Debian's documentation says you shouldn't need to prefix UUID with a ':', so remove that from auto.backup if the configuration you described doesn't work. Alternatively, you could specify its location as ":/dev/disk/by-uuid/<the disk id>".
On Wed, Aug 23, 2017 at 12:03:12PM -0700, Gordon Messmer wrote:
On 08/21/2017 07:23 PM, Fred Smith wrote:
so, in my case, the USB drive contains an xfs filesystem. would I do something like this:
in /etc/auto.master: backup /etc/auto.backup
and in /etc/auto.backup backup -fstype=xfs,defaults,noauto,users :UUID=09bfc97a-8db2-46de-b4dd-427da19b114
In auto.master, the first field is a directory, so it should be "/backup".
Debian's documentation says you shouldn't need to prefix UUID with a ':', so remove that from auto.backup if the configuration you described doesn't work. Alternatively, you could specify its location as ":/dev/disk/by-uuid/<the disk id>".
Ok, when I actually tried it, I did it this way:
/etc/auto.master (excerpt):
/mnt /etc/auto.mnt
and /etc/auto.mnt:
backup -fstype=xfs,defaults,noauto,users,rw :UUID=09bfc97a-8db2-46de-b4dd-427da19b1143
and lo and behold, it works!
but...
I have a couple of other networked filesystems (cifs) that I have always mounted in /mnt. so, after accessing either of them, systemctl status autofs shows me this:
Aug 23 15:46:02 fcshome.stoneham.ma.us systemd[1]: Starting Automounts filesystems on demand... Aug 23 15:46:02 fcshome.stoneham.ma.us automount[11265]: setautomntent: lookup(sss): setautomntent: No such fil...ory Aug 23 15:46:02 fcshome.stoneham.ma.us systemd[1]: Started Automounts filesystems on demand. Aug 23 15:50:04 fcshome.stoneham.ma.us automount[11265]: key "syno-fredex" not found in map source(s). Aug 23 15:50:04 fcshome.stoneham.ma.us automount[11265]: key "syno-public" not found in map source(s).
the first error regarding setautomntent seems to be pretty universal, as I see lots of questions about it (and bugs filed against Fedora and RHEL) but no actual solution. the consensus is that it doesn't seem to prevent autofs from working. (there is a workaround that I haven't tried, and mention of a patch to sssd that I also haven't tried, and which apparently hasn't made it into RHEL 7.3 or Centos7.x).
so, the two lines saying: Key "syno-fredex" or key "syno-public" appear whenever I try to access one of those two filesystems. I AM NOT USING AUTOFS TO MANAGE THEM. they were mounting in /mnt, just like the automount I was asking about. thinking since autofs was looking in /mnt for the backup mount that it was getting all confuzzled, I changed the mount point of those other two filesystems, changed their entries in /etc/fstab, reran systemctl restart autofs then touched one of those cifs filesystems. Voila! the errors still appear in the output of systemctl status autofs.
Everything still appears to work, but I'm puzzled by those two errors.
Anyone got any good ideas on this?
thanks in advance!
Fred
On 08/23/2017 01:06 PM, Fred Smith wrote:
so, the two lines saying: Key "syno-fredex" or key "syno-public" appear whenever I try to access one of those two filesystems. I AM NOT USING AUTOFS TO MANAGE THEM.
You're using autofs to manage /mnt, so any time that *any* process attempts to access /mnt/syno-fredex or /mnt/syno-public, you'll get those errors. That's how autofs works: access attempts in an autofs managed directory get passed to autofs, which looks at its maps to determine how to mount the path being accessed. The error you see is autofs telling you that something is trying to access "syno-fredex" under /mnt, but it doesn't have a map indicating how to mount a filesystem in a directory of that name.
On Wed, Aug 23, 2017 at 01:59:23PM -0700, Gordon Messmer wrote:
On 08/23/2017 01:06 PM, Fred Smith wrote:
so, the two lines saying: Key "syno-fredex" or key "syno-public" appear whenever I try to access one of those two filesystems. I AM NOT USING AUTOFS TO MANAGE THEM.
You're using autofs to manage /mnt, so any time that *any* process attempts to access /mnt/syno-fredex or /mnt/syno-public, you'll get those errors. That's how autofs works: access attempts in an autofs managed directory get passed to autofs, which looks at its maps to determine how to mount the path being accessed. The error you see is autofs telling you that something is trying to access "syno-fredex" under /mnt, but it doesn't have a map indicating how to mount a filesystem in a directory of that name.
yeah, that's what I figured.
so I created /mounts and moved those two mounts to that directory. the restarted autofs, but the errors still come when accessing those two mounts.
do I need to reboot or something to get autofs to forget about them being in /mnt?
Thanks again!
On 08/23/2017 02:31 PM, Fred Smith wrote:
do I need to reboot or something to get autofs to forget about them being in /mnt?
No, you need to figure out what program, not autofs, is trying to access /mnt/syno-fredex and /mnt/syno-public.
You moved the mounts, but some program still expects those paths to exist. autofs is just telling you that some other program is still looking in that location.
On Wed, Aug 23, 2017 at 08:53:17PM -0700, Gordon Messmer wrote:
On 08/23/2017 02:31 PM, Fred Smith wrote:
do I need to reboot or something to get autofs to forget about them being in /mnt?
No, you need to figure out what program, not autofs, is trying to access /mnt/syno-fredex and /mnt/syno-public.
You moved the mounts, but some program still expects those paths to exist. autofs is just telling you that some other program is still looking in that location.
Gordon, thanks for the followup.
I have a desktop icon for opening a window in each of those two mounts (the mounts occur at system boot), the icons are backed up by .desktop files:
cat NAS-fredex.desktop #!/usr/bin/env xdg-open
[Desktop Entry] Version=1.0 Type=Link Icon[en_US]=system-logo-icon Name[en_US]=NAS-fredex URL=/mounts/syno-fredex Name=NAS-fredex Icon=/usr/share/icons/mate/48x48/places/network_local.png
cat NAS-public.desktop #!/usr/bin/env xdg-open
[Desktop Entry] Version=1.0 Type=Link Icon[en_US]=system-logo-icon Name[en_US]=NAS-public URL=/mounts/syno-public Name=NAS-public Icon=/usr/share/icons/mate/48x48/places/network_local.png
if I click one of those then run systemctl status autofs I see one of those errors show up. If I click on it again, there are two errors. if I click on the other one, a third error shows up.
nothing else I've tried seems to cause them to show up.
as you can see, neither of them refers to the old mount point on /mnt.
I know you can't look thru my computer and see what's wrong, but I'm puzzl-ified, since /mnt/syno-public isn't mentioned anywhere in the .desktop files. If you can think of anything else that might be happening, I'd appreciate your wisdom.
thanks once again!
Fred
On 08/24/2017 06:55 PM, Fred Smith wrote:
if I click one of those then run systemctl status autofs I see one of those errors show up. If I click on it again, there are two errors. if I click on the other one, a third error shows up.
Does your file manager have some other link to the old locations? A "favorites" entry? Something in the sidebar? More than likely, your file manager is trying to check the old location, not for its primary view which is /mounts/something, but for some other reason.
On Thu, Aug 24, 2017 at 11:04:05PM -0700, Gordon Messmer wrote:
On 08/24/2017 06:55 PM, Fred Smith wrote:
if I click one of those then run systemctl status autofs I see one of those errors show up. If I click on it again, there are two errors. if I click on the other one, a third error shows up.
Does your file manager have some other link to the old locations? A "favorites" entry? Something in the sidebar? More than likely, your file manager is trying to check the old location, not for its primary view which is /mounts/something, but for some other reason.
don't think so. I'm running the Mate desktop. Original install was Gnome (which is I assume what you are thinking of) but I never use it, can't stand Gnome-3.x.
Don't know of anything in mate that would do th at, but I'll do some digging around.
thanks once again!
On 08/25/2017 08:32 AM, Fred Smith wrote:
Don't know of anything in mate that would do th at, but I'll do some digging around.
You can always look the hard/slow way:
find ~ -type f -exec fgrep /mnt/syno {} +
That command should locate any files that refer to the old mount locations.
On Fri, Aug 25, 2017 at 09:37:59AM -0700, Gordon Messmer wrote:
On 08/25/2017 08:32 AM, Fred Smith wrote:
Don't know of anything in mate that would do th at, but I'll do some digging around.
You can always look the hard/slow way:
find ~ -type f -exec fgrep /mnt/syno {} +
That command should locate any files that refer to the old mount locations.
a bunch of things that look merely like log files.
so, in the meantime I did the update for all the files sitting in the CR repo. rebooted. now the problem is gone. Go figure.
-
Fred Smith -
Gordon Messmer