Autofs doesn't mount shares on startup












10














I am using OpenSuSE 12.1 with homes shared through LDAP and NFS.
ldap stores the maps.
My problem is I can't have the shares mounted on boot. It's only working when restarting the autofs service manually.
On a CentOS 6.3 there is no such problem.



My /etc/nsswitch.conf:



passwd: files sss
group: files sss

hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files dns

services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files

bootparams: files
automount: files ldap
aliases: files


My /etc/openldap/ldap.conf:



SIZELIMIT       20
TIMELIMIT 15
#DEREF never
TLS_REQCERT demand
uri ldap://10.0.0.1
base dc=domain,dc=com


My /etc/sssd/sssd.conf:



[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = domain.com

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/domain.com]
id_provider = ldap
auth_provider = ldap
min_id = 500
max_id = 30000
ldap_schema = rfc2307
ldap_uri = ldaps://ldap-ms.local, ldaps://ldap-sl.local, ldap://ldap
ldap_search_base = dc=domain,dc=com
ldap_user_search_base = ou=People,dc=domain,dc=com
ldap_group_search_base = ou=Group,dc=domain,dc=com
ldap_tls_cacert = /etc/pki/CA/certs/domain-cacert.pem
ldap_tls_reqcert = hard
cache_credentials = true
enumerate = True


My /etc/sysconfig/autofs:



MASTER_MAP_NAME="auto.master"
TIMEOUT=300
BROWSE_MODE="yes"
MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="ou"
ENTRY_ATTRIBUTE="cn"
VALUE_ATTRIBUTE="automountInformation"
USE_MISC_DEVICE="yes"


Am I missing something?










share|improve this question




















  • 2




    Any chance your LDAP service is not available with the maps in time for the booting file system query? That would explain the later success with restart once the system is up and stable.
    – zedman9991
    Jul 13 '12 at 17:57












  • What are the start-levels (within your target runlevel) for autofs and your ldap-client?
    – Nils
    Jul 13 '12 at 20:09










  • @zedman9991 This problem occurs only with my version of opensuse (12.1) On Centos 6.3 and OpenSuse 11.2 it works fine.
    – igor012
    Jul 16 '12 at 9:02










  • @Nils Autofs starts on runlevels 3 and 5.
    – igor012
    Jul 16 '12 at 9:02










  • There is a difference in the way autofs mounts maps on boot on opensuse 11.2 it mounts them at the access but on opensuse 12.1 it mounts them all but no access.
    – igor012
    Jul 16 '12 at 10:04


















10














I am using OpenSuSE 12.1 with homes shared through LDAP and NFS.
ldap stores the maps.
My problem is I can't have the shares mounted on boot. It's only working when restarting the autofs service manually.
On a CentOS 6.3 there is no such problem.



My /etc/nsswitch.conf:



passwd: files sss
group: files sss

hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files dns

services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files

bootparams: files
automount: files ldap
aliases: files


My /etc/openldap/ldap.conf:



SIZELIMIT       20
TIMELIMIT 15
#DEREF never
TLS_REQCERT demand
uri ldap://10.0.0.1
base dc=domain,dc=com


My /etc/sssd/sssd.conf:



[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = domain.com

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/domain.com]
id_provider = ldap
auth_provider = ldap
min_id = 500
max_id = 30000
ldap_schema = rfc2307
ldap_uri = ldaps://ldap-ms.local, ldaps://ldap-sl.local, ldap://ldap
ldap_search_base = dc=domain,dc=com
ldap_user_search_base = ou=People,dc=domain,dc=com
ldap_group_search_base = ou=Group,dc=domain,dc=com
ldap_tls_cacert = /etc/pki/CA/certs/domain-cacert.pem
ldap_tls_reqcert = hard
cache_credentials = true
enumerate = True


My /etc/sysconfig/autofs:



MASTER_MAP_NAME="auto.master"
TIMEOUT=300
BROWSE_MODE="yes"
MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="ou"
ENTRY_ATTRIBUTE="cn"
VALUE_ATTRIBUTE="automountInformation"
USE_MISC_DEVICE="yes"


Am I missing something?










share|improve this question




















  • 2




    Any chance your LDAP service is not available with the maps in time for the booting file system query? That would explain the later success with restart once the system is up and stable.
    – zedman9991
    Jul 13 '12 at 17:57












  • What are the start-levels (within your target runlevel) for autofs and your ldap-client?
    – Nils
    Jul 13 '12 at 20:09










  • @zedman9991 This problem occurs only with my version of opensuse (12.1) On Centos 6.3 and OpenSuse 11.2 it works fine.
    – igor012
    Jul 16 '12 at 9:02










  • @Nils Autofs starts on runlevels 3 and 5.
    – igor012
    Jul 16 '12 at 9:02










  • There is a difference in the way autofs mounts maps on boot on opensuse 11.2 it mounts them at the access but on opensuse 12.1 it mounts them all but no access.
    – igor012
    Jul 16 '12 at 10:04
















10












10








10







I am using OpenSuSE 12.1 with homes shared through LDAP and NFS.
ldap stores the maps.
My problem is I can't have the shares mounted on boot. It's only working when restarting the autofs service manually.
On a CentOS 6.3 there is no such problem.



My /etc/nsswitch.conf:



passwd: files sss
group: files sss

hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files dns

services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files

bootparams: files
automount: files ldap
aliases: files


My /etc/openldap/ldap.conf:



SIZELIMIT       20
TIMELIMIT 15
#DEREF never
TLS_REQCERT demand
uri ldap://10.0.0.1
base dc=domain,dc=com


My /etc/sssd/sssd.conf:



[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = domain.com

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/domain.com]
id_provider = ldap
auth_provider = ldap
min_id = 500
max_id = 30000
ldap_schema = rfc2307
ldap_uri = ldaps://ldap-ms.local, ldaps://ldap-sl.local, ldap://ldap
ldap_search_base = dc=domain,dc=com
ldap_user_search_base = ou=People,dc=domain,dc=com
ldap_group_search_base = ou=Group,dc=domain,dc=com
ldap_tls_cacert = /etc/pki/CA/certs/domain-cacert.pem
ldap_tls_reqcert = hard
cache_credentials = true
enumerate = True


My /etc/sysconfig/autofs:



MASTER_MAP_NAME="auto.master"
TIMEOUT=300
BROWSE_MODE="yes"
MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="ou"
ENTRY_ATTRIBUTE="cn"
VALUE_ATTRIBUTE="automountInformation"
USE_MISC_DEVICE="yes"


Am I missing something?










share|improve this question















I am using OpenSuSE 12.1 with homes shared through LDAP and NFS.
ldap stores the maps.
My problem is I can't have the shares mounted on boot. It's only working when restarting the autofs service manually.
On a CentOS 6.3 there is no such problem.



My /etc/nsswitch.conf:



passwd: files sss
group: files sss

hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files dns

services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files

bootparams: files
automount: files ldap
aliases: files


My /etc/openldap/ldap.conf:



SIZELIMIT       20
TIMELIMIT 15
#DEREF never
TLS_REQCERT demand
uri ldap://10.0.0.1
base dc=domain,dc=com


My /etc/sssd/sssd.conf:



[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = domain.com

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/domain.com]
id_provider = ldap
auth_provider = ldap
min_id = 500
max_id = 30000
ldap_schema = rfc2307
ldap_uri = ldaps://ldap-ms.local, ldaps://ldap-sl.local, ldap://ldap
ldap_search_base = dc=domain,dc=com
ldap_user_search_base = ou=People,dc=domain,dc=com
ldap_group_search_base = ou=Group,dc=domain,dc=com
ldap_tls_cacert = /etc/pki/CA/certs/domain-cacert.pem
ldap_tls_reqcert = hard
cache_credentials = true
enumerate = True


My /etc/sysconfig/autofs:



MASTER_MAP_NAME="auto.master"
TIMEOUT=300
BROWSE_MODE="yes"
MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="ou"
ENTRY_ATTRIBUTE="cn"
VALUE_ATTRIBUTE="automountInformation"
USE_MISC_DEVICE="yes"


Am I missing something?







opensuse nfs ldap autofs






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 10 at 5:29









Filipe Brandenburger

6,9152735




6,9152735










asked Jul 13 '12 at 13:38









igor012

3031412




3031412








  • 2




    Any chance your LDAP service is not available with the maps in time for the booting file system query? That would explain the later success with restart once the system is up and stable.
    – zedman9991
    Jul 13 '12 at 17:57












  • What are the start-levels (within your target runlevel) for autofs and your ldap-client?
    – Nils
    Jul 13 '12 at 20:09










  • @zedman9991 This problem occurs only with my version of opensuse (12.1) On Centos 6.3 and OpenSuse 11.2 it works fine.
    – igor012
    Jul 16 '12 at 9:02










  • @Nils Autofs starts on runlevels 3 and 5.
    – igor012
    Jul 16 '12 at 9:02










  • There is a difference in the way autofs mounts maps on boot on opensuse 11.2 it mounts them at the access but on opensuse 12.1 it mounts them all but no access.
    – igor012
    Jul 16 '12 at 10:04
















  • 2




    Any chance your LDAP service is not available with the maps in time for the booting file system query? That would explain the later success with restart once the system is up and stable.
    – zedman9991
    Jul 13 '12 at 17:57












  • What are the start-levels (within your target runlevel) for autofs and your ldap-client?
    – Nils
    Jul 13 '12 at 20:09










  • @zedman9991 This problem occurs only with my version of opensuse (12.1) On Centos 6.3 and OpenSuse 11.2 it works fine.
    – igor012
    Jul 16 '12 at 9:02










  • @Nils Autofs starts on runlevels 3 and 5.
    – igor012
    Jul 16 '12 at 9:02










  • There is a difference in the way autofs mounts maps on boot on opensuse 11.2 it mounts them at the access but on opensuse 12.1 it mounts them all but no access.
    – igor012
    Jul 16 '12 at 10:04










2




2




Any chance your LDAP service is not available with the maps in time for the booting file system query? That would explain the later success with restart once the system is up and stable.
– zedman9991
Jul 13 '12 at 17:57






Any chance your LDAP service is not available with the maps in time for the booting file system query? That would explain the later success with restart once the system is up and stable.
– zedman9991
Jul 13 '12 at 17:57














What are the start-levels (within your target runlevel) for autofs and your ldap-client?
– Nils
Jul 13 '12 at 20:09




What are the start-levels (within your target runlevel) for autofs and your ldap-client?
– Nils
Jul 13 '12 at 20:09












@zedman9991 This problem occurs only with my version of opensuse (12.1) On Centos 6.3 and OpenSuse 11.2 it works fine.
– igor012
Jul 16 '12 at 9:02




@zedman9991 This problem occurs only with my version of opensuse (12.1) On Centos 6.3 and OpenSuse 11.2 it works fine.
– igor012
Jul 16 '12 at 9:02












@Nils Autofs starts on runlevels 3 and 5.
– igor012
Jul 16 '12 at 9:02




@Nils Autofs starts on runlevels 3 and 5.
– igor012
Jul 16 '12 at 9:02












There is a difference in the way autofs mounts maps on boot on opensuse 11.2 it mounts them at the access but on opensuse 12.1 it mounts them all but no access.
– igor012
Jul 16 '12 at 10:04






There is a difference in the way autofs mounts maps on boot on opensuse 11.2 it mounts them at the access but on opensuse 12.1 it mounts them all but no access.
– igor012
Jul 16 '12 at 10:04












2 Answers
2






active

oldest

votes


















0














Why not just add the mount locations to your fstab.



You could also use sshfs.
Configure ssh to use public key authentication.




On the server:

sudo apt-get install openssh-server

Change to or add ServerKeyBits 2048 to /etc/ssh/sshd_config




On the Client

ssh-keygen -t rsa -b 2048

ssh-copy-id from the client computer to the server.
Use your password for your user on the server machine to login

Change /etc/ssh/sshd_config: PasswordAuthentication no, UsePAM no

I use other settings as well to harden ssh but for this example it is not needed.

If your outside your lan setup a dyndns or noip updater, and setup portforwarding on your router so port 23 or what ever port you decide to use to obfuscate the service is forwarded to the server ip address, if you need help with that just ask.




Then:

sshfs USER@SERVERADDRESS:/mnt/DRIVELOCATION /PATH/TO/MOUNT/DRIVE/TO

I set this command as a launcher on the main menu for some drives and for others in the fstab.

I know it works because I use this same setup plus the hardening everyday.

This way you can get rid of the need for autofs and its required overhead.






share|improve this answer































    0














    This question got bumped by community, and it's pretty old.

    A lot of things has happened over the years, Michael mentioned one solution, using fstab. And the original problem was most likely do due execution-order at boot time. Network might not have been ready, some service might not have started etc.



    There's also another solution if you're running systemd (which I doubt OP did at the time, but if you end up here through a search, and you do) here's another solution using systemd's automount feature.



    [Unit]
    Description=Network mapping
    After=network.target

    [Mount]
    What=10.0.0.1:/share/stuff
    Where=/mnt/remote_share
    Type=nfs
    Options=_netdev,auto

    [Install]
    WantedBy=multi-user.target


    The only drawback of this is that you have to be careful with what you name the service script. It's best described here, but a tl;dr-version is that the service-file must be named after the path it's going to mount. And all forward-slashes in said path has to be replaced with - in the service-file name for automatic mounting to work. The above example of /mnt/remote_share would be a service-file calledmnt-remote_share.mount`



    There's a bunch of options to go with this.

    If systemd isn't your thing, there's also a lot of new stuff on the autofs side which does a pretty good job (all be it a bit complicated for my taste).



    If you want to use a fstab entry instead but utilize systemd's auto-hook feature, here's what your fstab could look like:



    10.0.0.1:/share/stuff   /mnt/remote_share  nfs  noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0


    And if neither of those work, there's also the pure-fstab solution:



    10.0.0.1:/share/stuff   /mnt/remote_share   nfs   defaults,soft,rsize=32768,wsize=32768,timeo=900,retrans=5,_netdev 0 0


    I'll drop a few links to good documentation on the subject (bare in mind, it's a different OS. But their Wiki is as of writing this one of the best on the market):




    • https://wiki.archlinux.org/index.php/NFS#Mount_using_/etc/fstab_with_systemd

    • https://wiki.archlinux.org/index.php/autofs

    • https://wiki.archlinux.org/index.php/Autofs#NFS_network_mounts


    For any traveler across the internet ending up here, hope any of this helps.






    share|improve this answer























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "106"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f42963%2fautofs-doesnt-mount-shares-on-startup%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      0














      Why not just add the mount locations to your fstab.



      You could also use sshfs.
      Configure ssh to use public key authentication.




      On the server:

      sudo apt-get install openssh-server

      Change to or add ServerKeyBits 2048 to /etc/ssh/sshd_config




      On the Client

      ssh-keygen -t rsa -b 2048

      ssh-copy-id from the client computer to the server.
      Use your password for your user on the server machine to login

      Change /etc/ssh/sshd_config: PasswordAuthentication no, UsePAM no

      I use other settings as well to harden ssh but for this example it is not needed.

      If your outside your lan setup a dyndns or noip updater, and setup portforwarding on your router so port 23 or what ever port you decide to use to obfuscate the service is forwarded to the server ip address, if you need help with that just ask.




      Then:

      sshfs USER@SERVERADDRESS:/mnt/DRIVELOCATION /PATH/TO/MOUNT/DRIVE/TO

      I set this command as a launcher on the main menu for some drives and for others in the fstab.

      I know it works because I use this same setup plus the hardening everyday.

      This way you can get rid of the need for autofs and its required overhead.






      share|improve this answer




























        0














        Why not just add the mount locations to your fstab.



        You could also use sshfs.
        Configure ssh to use public key authentication.




        On the server:

        sudo apt-get install openssh-server

        Change to or add ServerKeyBits 2048 to /etc/ssh/sshd_config




        On the Client

        ssh-keygen -t rsa -b 2048

        ssh-copy-id from the client computer to the server.
        Use your password for your user on the server machine to login

        Change /etc/ssh/sshd_config: PasswordAuthentication no, UsePAM no

        I use other settings as well to harden ssh but for this example it is not needed.

        If your outside your lan setup a dyndns or noip updater, and setup portforwarding on your router so port 23 or what ever port you decide to use to obfuscate the service is forwarded to the server ip address, if you need help with that just ask.




        Then:

        sshfs USER@SERVERADDRESS:/mnt/DRIVELOCATION /PATH/TO/MOUNT/DRIVE/TO

        I set this command as a launcher on the main menu for some drives and for others in the fstab.

        I know it works because I use this same setup plus the hardening everyday.

        This way you can get rid of the need for autofs and its required overhead.






        share|improve this answer


























          0












          0








          0






          Why not just add the mount locations to your fstab.



          You could also use sshfs.
          Configure ssh to use public key authentication.




          On the server:

          sudo apt-get install openssh-server

          Change to or add ServerKeyBits 2048 to /etc/ssh/sshd_config




          On the Client

          ssh-keygen -t rsa -b 2048

          ssh-copy-id from the client computer to the server.
          Use your password for your user on the server machine to login

          Change /etc/ssh/sshd_config: PasswordAuthentication no, UsePAM no

          I use other settings as well to harden ssh but for this example it is not needed.

          If your outside your lan setup a dyndns or noip updater, and setup portforwarding on your router so port 23 or what ever port you decide to use to obfuscate the service is forwarded to the server ip address, if you need help with that just ask.




          Then:

          sshfs USER@SERVERADDRESS:/mnt/DRIVELOCATION /PATH/TO/MOUNT/DRIVE/TO

          I set this command as a launcher on the main menu for some drives and for others in the fstab.

          I know it works because I use this same setup plus the hardening everyday.

          This way you can get rid of the need for autofs and its required overhead.






          share|improve this answer














          Why not just add the mount locations to your fstab.



          You could also use sshfs.
          Configure ssh to use public key authentication.




          On the server:

          sudo apt-get install openssh-server

          Change to or add ServerKeyBits 2048 to /etc/ssh/sshd_config




          On the Client

          ssh-keygen -t rsa -b 2048

          ssh-copy-id from the client computer to the server.
          Use your password for your user on the server machine to login

          Change /etc/ssh/sshd_config: PasswordAuthentication no, UsePAM no

          I use other settings as well to harden ssh but for this example it is not needed.

          If your outside your lan setup a dyndns or noip updater, and setup portforwarding on your router so port 23 or what ever port you decide to use to obfuscate the service is forwarded to the server ip address, if you need help with that just ask.




          Then:

          sshfs USER@SERVERADDRESS:/mnt/DRIVELOCATION /PATH/TO/MOUNT/DRIVE/TO

          I set this command as a launcher on the main menu for some drives and for others in the fstab.

          I know it works because I use this same setup plus the hardening everyday.

          This way you can get rid of the need for autofs and its required overhead.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 17 at 22:18

























          answered Nov 17 at 19:46









          Michael Prokopec

          1,022116




          1,022116

























              0














              This question got bumped by community, and it's pretty old.

              A lot of things has happened over the years, Michael mentioned one solution, using fstab. And the original problem was most likely do due execution-order at boot time. Network might not have been ready, some service might not have started etc.



              There's also another solution if you're running systemd (which I doubt OP did at the time, but if you end up here through a search, and you do) here's another solution using systemd's automount feature.



              [Unit]
              Description=Network mapping
              After=network.target

              [Mount]
              What=10.0.0.1:/share/stuff
              Where=/mnt/remote_share
              Type=nfs
              Options=_netdev,auto

              [Install]
              WantedBy=multi-user.target


              The only drawback of this is that you have to be careful with what you name the service script. It's best described here, but a tl;dr-version is that the service-file must be named after the path it's going to mount. And all forward-slashes in said path has to be replaced with - in the service-file name for automatic mounting to work. The above example of /mnt/remote_share would be a service-file calledmnt-remote_share.mount`



              There's a bunch of options to go with this.

              If systemd isn't your thing, there's also a lot of new stuff on the autofs side which does a pretty good job (all be it a bit complicated for my taste).



              If you want to use a fstab entry instead but utilize systemd's auto-hook feature, here's what your fstab could look like:



              10.0.0.1:/share/stuff   /mnt/remote_share  nfs  noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0


              And if neither of those work, there's also the pure-fstab solution:



              10.0.0.1:/share/stuff   /mnt/remote_share   nfs   defaults,soft,rsize=32768,wsize=32768,timeo=900,retrans=5,_netdev 0 0


              I'll drop a few links to good documentation on the subject (bare in mind, it's a different OS. But their Wiki is as of writing this one of the best on the market):




              • https://wiki.archlinux.org/index.php/NFS#Mount_using_/etc/fstab_with_systemd

              • https://wiki.archlinux.org/index.php/autofs

              • https://wiki.archlinux.org/index.php/Autofs#NFS_network_mounts


              For any traveler across the internet ending up here, hope any of this helps.






              share|improve this answer




























                0














                This question got bumped by community, and it's pretty old.

                A lot of things has happened over the years, Michael mentioned one solution, using fstab. And the original problem was most likely do due execution-order at boot time. Network might not have been ready, some service might not have started etc.



                There's also another solution if you're running systemd (which I doubt OP did at the time, but if you end up here through a search, and you do) here's another solution using systemd's automount feature.



                [Unit]
                Description=Network mapping
                After=network.target

                [Mount]
                What=10.0.0.1:/share/stuff
                Where=/mnt/remote_share
                Type=nfs
                Options=_netdev,auto

                [Install]
                WantedBy=multi-user.target


                The only drawback of this is that you have to be careful with what you name the service script. It's best described here, but a tl;dr-version is that the service-file must be named after the path it's going to mount. And all forward-slashes in said path has to be replaced with - in the service-file name for automatic mounting to work. The above example of /mnt/remote_share would be a service-file calledmnt-remote_share.mount`



                There's a bunch of options to go with this.

                If systemd isn't your thing, there's also a lot of new stuff on the autofs side which does a pretty good job (all be it a bit complicated for my taste).



                If you want to use a fstab entry instead but utilize systemd's auto-hook feature, here's what your fstab could look like:



                10.0.0.1:/share/stuff   /mnt/remote_share  nfs  noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0


                And if neither of those work, there's also the pure-fstab solution:



                10.0.0.1:/share/stuff   /mnt/remote_share   nfs   defaults,soft,rsize=32768,wsize=32768,timeo=900,retrans=5,_netdev 0 0


                I'll drop a few links to good documentation on the subject (bare in mind, it's a different OS. But their Wiki is as of writing this one of the best on the market):




                • https://wiki.archlinux.org/index.php/NFS#Mount_using_/etc/fstab_with_systemd

                • https://wiki.archlinux.org/index.php/autofs

                • https://wiki.archlinux.org/index.php/Autofs#NFS_network_mounts


                For any traveler across the internet ending up here, hope any of this helps.






                share|improve this answer


























                  0












                  0








                  0






                  This question got bumped by community, and it's pretty old.

                  A lot of things has happened over the years, Michael mentioned one solution, using fstab. And the original problem was most likely do due execution-order at boot time. Network might not have been ready, some service might not have started etc.



                  There's also another solution if you're running systemd (which I doubt OP did at the time, but if you end up here through a search, and you do) here's another solution using systemd's automount feature.



                  [Unit]
                  Description=Network mapping
                  After=network.target

                  [Mount]
                  What=10.0.0.1:/share/stuff
                  Where=/mnt/remote_share
                  Type=nfs
                  Options=_netdev,auto

                  [Install]
                  WantedBy=multi-user.target


                  The only drawback of this is that you have to be careful with what you name the service script. It's best described here, but a tl;dr-version is that the service-file must be named after the path it's going to mount. And all forward-slashes in said path has to be replaced with - in the service-file name for automatic mounting to work. The above example of /mnt/remote_share would be a service-file calledmnt-remote_share.mount`



                  There's a bunch of options to go with this.

                  If systemd isn't your thing, there's also a lot of new stuff on the autofs side which does a pretty good job (all be it a bit complicated for my taste).



                  If you want to use a fstab entry instead but utilize systemd's auto-hook feature, here's what your fstab could look like:



                  10.0.0.1:/share/stuff   /mnt/remote_share  nfs  noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0


                  And if neither of those work, there's also the pure-fstab solution:



                  10.0.0.1:/share/stuff   /mnt/remote_share   nfs   defaults,soft,rsize=32768,wsize=32768,timeo=900,retrans=5,_netdev 0 0


                  I'll drop a few links to good documentation on the subject (bare in mind, it's a different OS. But their Wiki is as of writing this one of the best on the market):




                  • https://wiki.archlinux.org/index.php/NFS#Mount_using_/etc/fstab_with_systemd

                  • https://wiki.archlinux.org/index.php/autofs

                  • https://wiki.archlinux.org/index.php/Autofs#NFS_network_mounts


                  For any traveler across the internet ending up here, hope any of this helps.






                  share|improve this answer














                  This question got bumped by community, and it's pretty old.

                  A lot of things has happened over the years, Michael mentioned one solution, using fstab. And the original problem was most likely do due execution-order at boot time. Network might not have been ready, some service might not have started etc.



                  There's also another solution if you're running systemd (which I doubt OP did at the time, but if you end up here through a search, and you do) here's another solution using systemd's automount feature.



                  [Unit]
                  Description=Network mapping
                  After=network.target

                  [Mount]
                  What=10.0.0.1:/share/stuff
                  Where=/mnt/remote_share
                  Type=nfs
                  Options=_netdev,auto

                  [Install]
                  WantedBy=multi-user.target


                  The only drawback of this is that you have to be careful with what you name the service script. It's best described here, but a tl;dr-version is that the service-file must be named after the path it's going to mount. And all forward-slashes in said path has to be replaced with - in the service-file name for automatic mounting to work. The above example of /mnt/remote_share would be a service-file calledmnt-remote_share.mount`



                  There's a bunch of options to go with this.

                  If systemd isn't your thing, there's also a lot of new stuff on the autofs side which does a pretty good job (all be it a bit complicated for my taste).



                  If you want to use a fstab entry instead but utilize systemd's auto-hook feature, here's what your fstab could look like:



                  10.0.0.1:/share/stuff   /mnt/remote_share  nfs  noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0


                  And if neither of those work, there's also the pure-fstab solution:



                  10.0.0.1:/share/stuff   /mnt/remote_share   nfs   defaults,soft,rsize=32768,wsize=32768,timeo=900,retrans=5,_netdev 0 0


                  I'll drop a few links to good documentation on the subject (bare in mind, it's a different OS. But their Wiki is as of writing this one of the best on the market):




                  • https://wiki.archlinux.org/index.php/NFS#Mount_using_/etc/fstab_with_systemd

                  • https://wiki.archlinux.org/index.php/autofs

                  • https://wiki.archlinux.org/index.php/Autofs#NFS_network_mounts


                  For any traveler across the internet ending up here, hope any of this helps.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Nov 17 at 22:37

























                  answered Nov 17 at 22:31









                  Torxed

                  1,22441634




                  1,22441634






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f42963%2fautofs-doesnt-mount-shares-on-startup%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Morgemoulin

                      Scott Moir

                      Souastre