Autofs stop working on Mageia 5

[c0legota]

Hi!

just upgraded from Mageia 4 to 5 two computers (an i586 old netbook and a x86_64 laptop). Since Mageia 2 I was using Autofs to mount partitions in my NAS system as described here. Once I've upgraded to Mageia 5 I can't see NAS partitions mounted in my computers.

I have the procedure saved and repeat it every time I upgrade, it's as follows and its taken from here (in Spanish).

Install Autofs

Code: Select all

# urpmi autofs


Create directory where I want my mount, in my case "/colenas" and give it permisions.

Code: Select all

[root@localhost colegota]# mkdir /colenas
[root@localhost colegota]# chmod a+r+w+x /colenas


Edit /etc/hosts (192.168.1.34 it's my NAS's IP)

Code: Select all

[colegota@alforjas ~]$ cat /etc/hosts
# generated by drakconnect
127.0.0.1 alforjas
127.0.0.1 localhost
192.168.1.34 colenas nas

Edit auto.master pointing to file auto.nas

Code: Select all

[root@localhost colegota]# cat /etc/autofs/auto.master
#
# 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
#
# NOTE: mounts done from a hosts map will be mounted with the
#       "nosuid" and "nodev" options unless the "suid" and "dev"
#       options are explicitly given.
#
#/net   -hosts
#
# Include /etc/auto.master.d/*.autofs
#
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master

#___ colenas desmontaje a 60 segundos ___

/colenas /etc/autofs/auto.nas --timeout=60

Note: did read this post talking about a bug to use /net but I never used it, while I've tried to change the line for /net /etc/autofs/auto.net but did not work.
viewtopic.php?f=15&t=8836&hilit=autofs

Edit auto.nas

Code: Select all

[root@localhost colegota]# cat /etc/autofs/auto.nas

Code: Select all

labo            -fstype=cifs,users,guest,iocharset=utf8,file_mode=0666,dir_mode=0777   ://192.168.1.34/Public/labo
public          -fstype=cifs,users,guest,iocharset=utf8,file_mode=0666,dir_mode=0777   ://192.168.1.34/public
mula          -fstype=cifs,users,guest,iocharset=utf8,file_mode=0666,dir_mode=0777   ://192.168.1.34/Download

Restart service

Code: Select all

systemctl restart autofs.service

I suppose something has changed in Mageia 5 respect previous versions but don't know what.
Anyone can help me?

Regards!
Colegota

[doktor5000]

Please show the output as root of

Code: Select all

systemctl status autofs.service -a -n50

[c0legota]

Thanks for your help!

Code: Select all

[root@alforjas colegota]# systemctl status autofs.service -a -n50
● autofs.service - Automounts filesystems on demand
   Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled)
   Active: active (running) since mar 2016-01-26 17:58:21 CET; 31min ago
  Process: 2605 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid (code=exited, status=0/SUCCESS)
 Main PID: 2618 (automount)
   CGroup: /system.slice/autofs.service
           └─2618 /usr/sbin/automount --pid-file /run/autofs.pid

[doktor5000]

You do have cifs-utils and keyutils installed? Please also post the contents of /etc/request-key.conf

Then do the following as root

Code: Select all

systemctl restart autofs.service
journalctl -af

open another terminal, and run

Code: Select all

ls -al /colenas

then wait a few seconds and also post the output from the two terminals, but separately please.

[c0legota]

BTW just seen that today I have access to one of three mount points

Code: Select all

[root@alforjas colegota]# ls /colenas
mula/


Until yesterday (and after some restarts) ls command didn't produce nothing.

Don't know why today I have access to this one and how to get access to the other two.

Under mula/ I have mounted mldonkey directories that it's running at NAS and managed by web browser from my pc.

I'm connecting other directories in the NAS (public/ and labo/) using Dolphin->Samba Network shares, while it's slow. Really slow sometimes.

[c0legota]

Didn't notice this answer when replayed last time...

You do have cifs-utils and keyutils installed?

Yes

Please also post the contents of /etc/request-key.conf

Code: Select all

[root@alforjas colegota]# cat /etc/request-key.conf
###############################################################################
#
# Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.                                                                 
# Written by David Howells (dhowells@redhat.com)                                                                       
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version
# 2 of the License, or (at your option) any later version.
#
###############################################################################


###############################################################################
#
# We can run programs or scripts
# - Macro substitutions in arguments:
#       %%...   %...
#       %o      operation name
#       %k      ID of key being operated upon
#       %t      type of key being operated upon
#       %d      description of key being operated upon
#       %c      callout info
#       %u      UID of requestor
#       %g      GID of requestor
#       %T      thread keyring of requestor (may be 0)
#       %P      process keyring of requestor (may be 0)
#       %S      session keyring of requestor (may be the user's default session)
#
################################################################################

#OP     TYPE    DESCRIPTION     CALLOUT INFO    PROGRAM ARG1 ARG2 ARG3 ...
#====== ======= =============== =============== ===============================
create  dns_resolver *          *               /sbin/key.dns_resolver %k
create  user    debug:*         negate          /bin/keyctl negate %k 30 %S
create  user    debug:*         rejected        /bin/keyctl reject %k 30 %c %S
create  user    debug:*         expired         /bin/keyctl reject %k 30 %c %S
create  user    debug:*         revoked         /bin/keyctl reject %k 30 %c %S
create  user    debug:loop:*    *               |/bin/cat
create  user    debug:*         *               /usr/share/keyutils/request-key-debug.sh %k %d %c %S
negate  *       *               *               /bin/keyctl negate %k 30 %S
create  cifs.spnego     *       *               /sbin/cifs.upcall -c %k
create  dns_resolver    *       *               /sbin/cifs.upcall %k


Then do the following as root

Code: Select all

systemctl restart autofs.service
journalctl -af

Code: Select all

[root@alforjas colegota]# systemctl restart autofs.service
[root@alforjas colegota]# journalctl -af
-- Logs begin at sáb 2016-01-23 13:14:14 CET. --
ene 26 22:04:19 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.67, on dev wlp3s0
ene 26 22:04:19 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..
ene 26 22:04:22 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.37, on dev wlp3s0
ene 26 22:04:22 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..
ene 26 22:04:22 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.37, on dev wlp3s0
ene 26 22:04:22 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..
ene 26 22:04:33 alforjas smbd[18514]: [2016/01/26 22:04:33.212253,  0] printing/print_cups.c:151(cups_connect)
ene 26 22:04:33 alforjas smbd[18514]: Unable to connect to CUPS server localhost:631 - Descriptor de fichero erróneo
ene 26 22:04:33 alforjas smbd[3027]: [2016/01/26 22:04:33.212392,  0] printing/print_cups.c:528(cups_async_callback)
ene 26 22:04:33 alforjas smbd[3027]: failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
^Tene 26 22:04:52 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.37, on dev wlp3s0
ene 26 22:04:52 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..
ene 26 22:04:52 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.37, on dev wlp3s0
ene 26 22:04:52 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..
ene 26 22:05:22 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.37, on dev wlp3s0
ene 26 22:05:22 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..
ene 26 22:05:22 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.37, on dev wlp3s0
ene 26 22:05:22 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..
ene 26 22:05:33 alforjas smbd[18628]: [2016/01/26 22:05:33.215830,  0] printing/print_cups.c:151(cups_connect)
ene 26 22:05:33 alforjas smbd[18628]: Unable to connect to CUPS server localhost:631 - Descriptor de fichero erróneo
ene 26 22:05:33 alforjas smbd[3027]: [2016/01/26 22:05:33.215954,  0] printing/print_cups.c:528(cups_async_callback)
ene 26 22:05:33 alforjas smbd[3027]: failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL


open another terminal, and run

Code: Select all

ls -al /colenas

then wait a few seconds and also post the output from the two terminals, but separately please.

Code: Select all

[colegota@alforjas ~]$ ls -al /colenas
total 4
drwxr-xr-x  2 root root    0 ene 26 22:04 ./
drwxr-xr-x 22 root root 4096 ene 24 18:17 ../


BTW As you can see now mula/ was not listed. Then back to dolphin where I have a "Place" mark for it, it reconnected and I can see mula again with

Code: Select all

[colegota@alforjas ~]$ ls -al /colenas
total 4
drwxr-xr-x  3 root root    0 ene 26 22:08 ./
drwxr-xr-x 22 root root 4096 ene 24 18:17 ../
drwxrwxrwx  2 root root    0 ene 26 18:55 mula

/

Messages from journalctl seems to be similar

This was in red colour:

Code: Select all

ene 26 22:10:33 alforjas smbd[18893]: [2016/01/26 22:10:33.500657,  0] printing/print_cups.c:151(cups_connect)
ene 26 22:10:33 alforjas smbd[18893]: Unable to connect to CUPS server localhost:631 - Descriptor de fichero erróneo
ene 26 22:10:33 alforjas smbd[3027]: [2016/01/26 22:10:33.500774,  0] printing/print_cups.c:528(cups_async_callback)
ene 26 22:10:33 alforjas smbd[3027]: failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL

This was in white colour:

Code: Select all

ene 26 22:10:52 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.37, on dev wlp3s0
ene 26 22:10:52 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..
ene 26 22:10:52 alforjas kernel: IPv4: martian source 192.168.1.255 from 192.168.1.37, on dev wlp3s0
ene 26 22:10:52 alforjas kernel: ll header: 00000000: ff ff ff ff ff ff 00 90 f5 db a4 79 08 00        ...........y..

[doktor5000]

Hmmm, I see nothing about cifs at all in the log excerpts ...
/etc/request-key.conf looks good, the last two lines are important for proper name resolution for cifs.

What happens if you manually mount such a share?

[c0legota]

Hmmm, I see nothing about cifs at all in the log excerpts ...
/etc/request-key.conf looks good, the last two lines are important for proper name resolution for cifs.

Yes, I'm using it for years...

What happens if you manually mount such a share?

With manual mount it works:

Code: Select all

# mount -t nfs 192.168.1.34:/public /mnt/Public

[root@alforjas colenas]# ls -la /mnt/Public/
total 104
drwxrwxrwx  9 root   root    4096 jul 26  2015 ./
drwxr-xr-x  3 root   root    4096 ene 27 17:35 ../
-rwxrwx---  1 nobody nogroup 1966 mar  8  2014 autofs.txt*
drwxrwx--- 17    500     500 4096 ene 19 17:30 copias/
-rwxrwx---  1 nobody nogroup 1207 feb  6  2013 du-colenas-20130206.txt*
-rwxrwx---  1 nobody nogroup 7724 jun  2  2013 du-colenas-20130601.txt*
-rwxrwx---  1 nobody nogroup 7588 jun  2  2013 du-colenas-20130601.txt~*
-rwxrwx---  1 nobody nogroup 1566 feb 22  2014 du-colenas-20140222.txt*
drwxrwx---  2 root   root    4096 may 27  2013 fototk/
drwxrwxrwx 13    500     500 4096 ene 27 06:49 labo/
drwxrwx---  2 root   root    4096 jun 15  2013 multi/
drwxrwx---  4 root   root    4096 ago  2  2013 nube/
drwxrwxrwx  8 nobody nogroup 4096 nov  1 10:45 red/
drwxrwxrwx  3    500     500 4096 may 17  2014 sincro/


[doktor5000]

What happens if you manually mount such a share?

With manual mount it works:

mount -t nfs 192.168.1.34:/public /mnt/Public

Err, the autofs entries want to mount a cifs share, you manually mounted a nfs share ... this doesn't really fit together ...

[c0legota]

Err, the autofs entries want to mount a cifs share, you manually mounted a nfs share ... this doesn't really fit together ...

Yes, sorry!
I were used to mount NFS before change to cifs with autofs.

Anyway, it also works.

Code: Select all

[root@alforjas Public]# mount -t cifs -o noperm //192.168.1.34/public /mnt/NASC
Password for colegota@//192.168.1.34/public:  ******

[root@alforjas NASC]# ls -la
total 25
drwxr-xr-x 2 root root    0 ene 27 18:04 ./
drwxr-xr-x 4 root root 4096 ene 27 20:52 ../
-rwxr-xr-x 1 root root 1966 mar  8  2014 autofs.txt*
drwxr-xr-x 2 root root    0 ene 19 17:30 copias/
-rwxr-xr-x 1 root root 1207 feb  6  2013 du-colenas-20130206.txt*
-rwxr-xr-x 1 root root 7724 jun  2  2013 du-colenas-20130601.txt*
-rwxr-xr-x 1 root root 7588 jun  2  2013 du-colenas-20130601.txt~*
-rwxr-xr-x 1 root root 1566 feb 22  2014 du-colenas-20140222.txt*
drwxr-xr-x 2 root root    0 may 27  2013 fototk/
drwxr-xr-x 2 root root    0 ene 27 06:49 labo/
drwxr-xr-x 2 root root    0 jun 15  2013 multi/
drwxr-xr-x 2 root root    0 ago  2  2013 nube/
drwxr-xr-x 2 root root    0 nov  1 10:45 red/
drwxr-xr-x 2 root root    0 may 17  2014 sincro/


In the meantime, I did noticed looking at NFS ls command that user ID 500 was not recognized and searching this forum I've found about the change to 1000 in Mageia 5.
Maybe it can be related with my problem?

Mounting with cifs, user and group it's shown always as root (I suppose it's the local directory owner) but mounting with NFS users are the ones created folders and files. I think was root for those created at NAS File Manager with admin account, 500 for those created with my user (colegota) using Dolphin or console from my laptop, and nobody user files maybe were created by another program like geeqie.

[doktor5000]

In the meantime, I did noticed looking at NFS ls command that user ID 500 was not recognized and searching this forum I've found about the change to 1000 in Mageia 5.
Maybe it can be related with my problem?

As a general hint and golden rule: Please only one problem per thread

Mounting with cifs, user and group it's shown always as root (I suppose it's the local directory owner) but mounting with NFS users are the ones created folders and files. I think was root for those created at NAS File Manager with admin account, 500 for those created with my user (colegota) using Dolphin or console from my laptop, and nobody user files maybe were created by another program like geeqie.

In the above example with the manual cifs mount, you mounted it without any options, i.e. as root. You would need to adapt the manual mount command so that it works and you have access as a user and then use the same mount options in /etc/auto.master

Start with something like

Code: Select all

mount -t cifs -o noperm,users,uid=500,gid=500,iocharset=utf8,file_mode=0666,dir_mode=0777 //192.168.1.34/public /mnt/NASC

and also check the options against the man page of mount.cifs

[c0legota]

In the meantime, I did noticed looking at NFS ls command that user ID 500 was not recognized and searching this forum I've found about the change to 1000 in Mageia 5.
Maybe it can be related with my problem?

As a general hint and golden rule: Please only one problem per thread

Of course!
My question was if autofs mounts failed due to the uid changes, because when I mount via NFS the files and directories created previously by user colegota was shown as user "500" because until Mageia 4 user ID for colegota was 500 and now it's 1000.
Just try to find any difference between this version and previous ones to try to explain the problem.

In the above example with the manual cifs mount, you mounted it without any options, i.e. as root. You would need to adapt the manual mount command so that it works and you have access as a user and then use the same mount options in /etc/auto.master

Start with something like

Code: Select all

mount -t cifs -o noperm,users,uid=500,gid=500,iocharset=utf8,file_mode=0666,dir_mode=0777 //192.168.1.34/public /mnt/NASC

and also check the options against the man page of mount.cifs

OK, sorry. Not at home now. I'll reply this later.

[c0legota]

Code: Select all

[root@alforjas colenas]# mount -t cifs -o noperm,users,uid=500,gid=500,iocharset=utf8,file_mode=0666,dir_mode=0777 //192.168.1.34/public /mnt/NASC
Password for colegota@//192.168.1.34/public:  ******
[root@alforjas colenas]# ls -la /mnt/NASC/
total 25
drwxrwxrwx 2  500  500    0 ene 27 18:04 ./
drwxr-xr-x 4 root root 4096 ene 27 20:52 ../
-rw-rw-rw- 1  500  500 1966 mar  8  2014 autofs.txt
drwxrwxrwx 2  500  500    0 ene 19 17:30 copias/
-rw-rw-rw- 1  500  500 1207 feb  6  2013 du-colenas-20130206.txt
-rw-rw-rw- 1  500  500 7724 jun  2  2013 du-colenas-20130601.txt
-rw-rw-rw- 1  500  500 7588 jun  2  2013 du-colenas-20130601.txt~
-rw-rw-rw- 1  500  500 1566 feb 22  2014 du-colenas-20140222.txt
drwxrwxrwx 2  500  500    0 may 27  2013 fototk/
drwxrwxrwx 2  500  500    0 ene 27 06:49 labo/
drwxrwxrwx 2  500  500    0 jun 15  2013 multi/
drwxrwxrwx 2  500  500    0 ago  2  2013 nube/
drwxrwxrwx 2  500  500    0 nov  1 10:45 red/
drwxrwxrwx 2  500  500    0 may 17  2014 sincro/


It works too. Just comparing with the previous mount with just noperm parameter, uid and gid was root, and with all the params are 500 (old version's uid for colegota).

Also notice that in both cases now I'm asked for colegota's password while in previous configurations for autofs I did no put the password anywhere and never asked for it before mount it.