How does _netdev mount option in /etc/fstab work?












20















I'd like to know what is the exact mechanism (implementation) used to defer mounting until after network interface is up when one uses _netdev option in /etc/fstab?

Does systemd alter this behavior?

Also, what does delay_connect option to sshfs provide what _netdev does not?



From mount man page:




_netdev

The filesystem resides on a device that requires network
access (used to prevent the system from attempting to mount
these filesystems until the network has been enabled on the
system).




From sshfs man page:




-o delay_connect

delay connection to server











share|improve this question





























    20















    I'd like to know what is the exact mechanism (implementation) used to defer mounting until after network interface is up when one uses _netdev option in /etc/fstab?

    Does systemd alter this behavior?

    Also, what does delay_connect option to sshfs provide what _netdev does not?



    From mount man page:




    _netdev

    The filesystem resides on a device that requires network
    access (used to prevent the system from attempting to mount
    these filesystems until the network has been enabled on the
    system).




    From sshfs man page:




    -o delay_connect

    delay connection to server











    share|improve this question



























      20












      20








      20


      2






      I'd like to know what is the exact mechanism (implementation) used to defer mounting until after network interface is up when one uses _netdev option in /etc/fstab?

      Does systemd alter this behavior?

      Also, what does delay_connect option to sshfs provide what _netdev does not?



      From mount man page:




      _netdev

      The filesystem resides on a device that requires network
      access (used to prevent the system from attempting to mount
      these filesystems until the network has been enabled on the
      system).




      From sshfs man page:




      -o delay_connect

      delay connection to server











      share|improve this question
















      I'd like to know what is the exact mechanism (implementation) used to defer mounting until after network interface is up when one uses _netdev option in /etc/fstab?

      Does systemd alter this behavior?

      Also, what does delay_connect option to sshfs provide what _netdev does not?



      From mount man page:




      _netdev

      The filesystem resides on a device that requires network
      access (used to prevent the system from attempting to mount
      these filesystems until the network has been enabled on the
      system).




      From sshfs man page:




      -o delay_connect

      delay connection to server








      mount systemd fstab automounting sshfs






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 24 '14 at 15:34









      eyoung100

      4,7881441




      4,7881441










      asked Nov 24 '14 at 13:55









      Piotr DobrogostPiotr Dobrogost

      1,02311533




      1,02311533






















          3 Answers
          3






          active

          oldest

          votes


















          18














          SysV Init



          The /etc/init.d/mountall.sh init script mounts local filesystems only:



          mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev


          Other filesystems are mounted by separate init scripts, like for example /etc/init.d/mountnfs.sh, which declare (via LSB headers) their dependency on $network. Thus these get scheduled later, after the network is brought up, while mountall.sh can run much earlier.



          systemd



          Local mount units are pulled in by local-fs.target, remote ones by remote-fs.target. systemd-fstab-generator scans /etc/fstab, generates mount units and assigns these to the above targets based on conditions similar to the above.



          delay_connect



          This option means that sshfs will not initiate the SSH connection to the remote server at mount time, but will only do so on the first filesystem operation actually requiring it. This delays error reporting, but might be a useful workaround in some cases, for example if your init system hasn't got enough information to order the mount operation correctly. "The network" being "up" is a rather loose term, and even though one can add arbitrary extra dependencies to mount units that doesn't help if the trigger event is not part of the bootup transaction (in systemd parlance).






          share|improve this answer


























          • So, you are saying that _netdev is not meant to be an argument passed to the process which performs mount (and which is specific to the type of mount like ext4/btrfs/cifs/fuse) but is meant to be read by other processes/scripts which based upon this flag decide when during the boot process these mounts should be executed. Yes? If so then I suspect this is the reason why this argument starts with underscore so that to differentiate it from other formal arguments.

            – Piotr Dobrogost
            May 12 '16 at 12:19











          • Yes. If you pass the _netdev option to the mount command, it will be visible in /proc/mounts but have no other effect.

            – Ferenc Wágner
            May 12 '16 at 14:07











          • Bonus question; is this documented somewhere?

            – Piotr Dobrogost
            May 12 '16 at 14:41






          • 1





            The mount manual contains: "FILESYSTEM-INDEPENDENT MOUNT OPTIONS — Some of these options are only useful when they appear in the /etc/fstab file." Well, _netdev (documented somewhat later) is a fine example for this.

            – Ferenc Wágner
            May 12 '16 at 15:04








          • 1





            The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. – bugzilla.redhat.com/show_bug.cgi?id=607309#c4

            – Piotr Dobrogost
            May 23 '16 at 8:01



















          12














          From man systemd.mount for version 231 of systemd:




          Mount units referring to local and network file systems are
          distinguished by their file
          system type specification. In some cases this is not sufficient (for example network block device based mounts, such as
          iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount
          unit a network mount.







          share|improve this answer
























          • Awsome! No idea why this answer hasn't been up-voted yet.

            – Valentin Bajrami
            Mar 7 '17 at 21:53



















          1














          Upstart/Udev



          For upstart and/or udev based systems this is slightly different.



          It seems udev will still try to mount the NFS filesystems and netfs is a safety net for when that fails.



          Please correct me if I'm wrong. either way, this answer is only relevant for some recent legacy systems (Ubuntu 14.04 LTS, RHEL6).






          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%2f169697%2fhow-does-netdev-mount-option-in-etc-fstab-work%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            18














            SysV Init



            The /etc/init.d/mountall.sh init script mounts local filesystems only:



            mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev


            Other filesystems are mounted by separate init scripts, like for example /etc/init.d/mountnfs.sh, which declare (via LSB headers) their dependency on $network. Thus these get scheduled later, after the network is brought up, while mountall.sh can run much earlier.



            systemd



            Local mount units are pulled in by local-fs.target, remote ones by remote-fs.target. systemd-fstab-generator scans /etc/fstab, generates mount units and assigns these to the above targets based on conditions similar to the above.



            delay_connect



            This option means that sshfs will not initiate the SSH connection to the remote server at mount time, but will only do so on the first filesystem operation actually requiring it. This delays error reporting, but might be a useful workaround in some cases, for example if your init system hasn't got enough information to order the mount operation correctly. "The network" being "up" is a rather loose term, and even though one can add arbitrary extra dependencies to mount units that doesn't help if the trigger event is not part of the bootup transaction (in systemd parlance).






            share|improve this answer


























            • So, you are saying that _netdev is not meant to be an argument passed to the process which performs mount (and which is specific to the type of mount like ext4/btrfs/cifs/fuse) but is meant to be read by other processes/scripts which based upon this flag decide when during the boot process these mounts should be executed. Yes? If so then I suspect this is the reason why this argument starts with underscore so that to differentiate it from other formal arguments.

              – Piotr Dobrogost
              May 12 '16 at 12:19











            • Yes. If you pass the _netdev option to the mount command, it will be visible in /proc/mounts but have no other effect.

              – Ferenc Wágner
              May 12 '16 at 14:07











            • Bonus question; is this documented somewhere?

              – Piotr Dobrogost
              May 12 '16 at 14:41






            • 1





              The mount manual contains: "FILESYSTEM-INDEPENDENT MOUNT OPTIONS — Some of these options are only useful when they appear in the /etc/fstab file." Well, _netdev (documented somewhat later) is a fine example for this.

              – Ferenc Wágner
              May 12 '16 at 15:04








            • 1





              The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. – bugzilla.redhat.com/show_bug.cgi?id=607309#c4

              – Piotr Dobrogost
              May 23 '16 at 8:01
















            18














            SysV Init



            The /etc/init.d/mountall.sh init script mounts local filesystems only:



            mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev


            Other filesystems are mounted by separate init scripts, like for example /etc/init.d/mountnfs.sh, which declare (via LSB headers) their dependency on $network. Thus these get scheduled later, after the network is brought up, while mountall.sh can run much earlier.



            systemd



            Local mount units are pulled in by local-fs.target, remote ones by remote-fs.target. systemd-fstab-generator scans /etc/fstab, generates mount units and assigns these to the above targets based on conditions similar to the above.



            delay_connect



            This option means that sshfs will not initiate the SSH connection to the remote server at mount time, but will only do so on the first filesystem operation actually requiring it. This delays error reporting, but might be a useful workaround in some cases, for example if your init system hasn't got enough information to order the mount operation correctly. "The network" being "up" is a rather loose term, and even though one can add arbitrary extra dependencies to mount units that doesn't help if the trigger event is not part of the bootup transaction (in systemd parlance).






            share|improve this answer


























            • So, you are saying that _netdev is not meant to be an argument passed to the process which performs mount (and which is specific to the type of mount like ext4/btrfs/cifs/fuse) but is meant to be read by other processes/scripts which based upon this flag decide when during the boot process these mounts should be executed. Yes? If so then I suspect this is the reason why this argument starts with underscore so that to differentiate it from other formal arguments.

              – Piotr Dobrogost
              May 12 '16 at 12:19











            • Yes. If you pass the _netdev option to the mount command, it will be visible in /proc/mounts but have no other effect.

              – Ferenc Wágner
              May 12 '16 at 14:07











            • Bonus question; is this documented somewhere?

              – Piotr Dobrogost
              May 12 '16 at 14:41






            • 1





              The mount manual contains: "FILESYSTEM-INDEPENDENT MOUNT OPTIONS — Some of these options are only useful when they appear in the /etc/fstab file." Well, _netdev (documented somewhat later) is a fine example for this.

              – Ferenc Wágner
              May 12 '16 at 15:04








            • 1





              The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. – bugzilla.redhat.com/show_bug.cgi?id=607309#c4

              – Piotr Dobrogost
              May 23 '16 at 8:01














            18












            18








            18







            SysV Init



            The /etc/init.d/mountall.sh init script mounts local filesystems only:



            mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev


            Other filesystems are mounted by separate init scripts, like for example /etc/init.d/mountnfs.sh, which declare (via LSB headers) their dependency on $network. Thus these get scheduled later, after the network is brought up, while mountall.sh can run much earlier.



            systemd



            Local mount units are pulled in by local-fs.target, remote ones by remote-fs.target. systemd-fstab-generator scans /etc/fstab, generates mount units and assigns these to the above targets based on conditions similar to the above.



            delay_connect



            This option means that sshfs will not initiate the SSH connection to the remote server at mount time, but will only do so on the first filesystem operation actually requiring it. This delays error reporting, but might be a useful workaround in some cases, for example if your init system hasn't got enough information to order the mount operation correctly. "The network" being "up" is a rather loose term, and even though one can add arbitrary extra dependencies to mount units that doesn't help if the trigger event is not part of the bootup transaction (in systemd parlance).






            share|improve this answer















            SysV Init



            The /etc/init.d/mountall.sh init script mounts local filesystems only:



            mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev


            Other filesystems are mounted by separate init scripts, like for example /etc/init.d/mountnfs.sh, which declare (via LSB headers) their dependency on $network. Thus these get scheduled later, after the network is brought up, while mountall.sh can run much earlier.



            systemd



            Local mount units are pulled in by local-fs.target, remote ones by remote-fs.target. systemd-fstab-generator scans /etc/fstab, generates mount units and assigns these to the above targets based on conditions similar to the above.



            delay_connect



            This option means that sshfs will not initiate the SSH connection to the remote server at mount time, but will only do so on the first filesystem operation actually requiring it. This delays error reporting, but might be a useful workaround in some cases, for example if your init system hasn't got enough information to order the mount operation correctly. "The network" being "up" is a rather loose term, and even though one can add arbitrary extra dependencies to mount units that doesn't help if the trigger event is not part of the bootup transaction (in systemd parlance).







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 29 at 12:11

























            answered Aug 30 '15 at 19:44









            Ferenc WágnerFerenc Wágner

            2,994920




            2,994920













            • So, you are saying that _netdev is not meant to be an argument passed to the process which performs mount (and which is specific to the type of mount like ext4/btrfs/cifs/fuse) but is meant to be read by other processes/scripts which based upon this flag decide when during the boot process these mounts should be executed. Yes? If so then I suspect this is the reason why this argument starts with underscore so that to differentiate it from other formal arguments.

              – Piotr Dobrogost
              May 12 '16 at 12:19











            • Yes. If you pass the _netdev option to the mount command, it will be visible in /proc/mounts but have no other effect.

              – Ferenc Wágner
              May 12 '16 at 14:07











            • Bonus question; is this documented somewhere?

              – Piotr Dobrogost
              May 12 '16 at 14:41






            • 1





              The mount manual contains: "FILESYSTEM-INDEPENDENT MOUNT OPTIONS — Some of these options are only useful when they appear in the /etc/fstab file." Well, _netdev (documented somewhat later) is a fine example for this.

              – Ferenc Wágner
              May 12 '16 at 15:04








            • 1





              The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. – bugzilla.redhat.com/show_bug.cgi?id=607309#c4

              – Piotr Dobrogost
              May 23 '16 at 8:01



















            • So, you are saying that _netdev is not meant to be an argument passed to the process which performs mount (and which is specific to the type of mount like ext4/btrfs/cifs/fuse) but is meant to be read by other processes/scripts which based upon this flag decide when during the boot process these mounts should be executed. Yes? If so then I suspect this is the reason why this argument starts with underscore so that to differentiate it from other formal arguments.

              – Piotr Dobrogost
              May 12 '16 at 12:19











            • Yes. If you pass the _netdev option to the mount command, it will be visible in /proc/mounts but have no other effect.

              – Ferenc Wágner
              May 12 '16 at 14:07











            • Bonus question; is this documented somewhere?

              – Piotr Dobrogost
              May 12 '16 at 14:41






            • 1





              The mount manual contains: "FILESYSTEM-INDEPENDENT MOUNT OPTIONS — Some of these options are only useful when they appear in the /etc/fstab file." Well, _netdev (documented somewhat later) is a fine example for this.

              – Ferenc Wágner
              May 12 '16 at 15:04








            • 1





              The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. – bugzilla.redhat.com/show_bug.cgi?id=607309#c4

              – Piotr Dobrogost
              May 23 '16 at 8:01

















            So, you are saying that _netdev is not meant to be an argument passed to the process which performs mount (and which is specific to the type of mount like ext4/btrfs/cifs/fuse) but is meant to be read by other processes/scripts which based upon this flag decide when during the boot process these mounts should be executed. Yes? If so then I suspect this is the reason why this argument starts with underscore so that to differentiate it from other formal arguments.

            – Piotr Dobrogost
            May 12 '16 at 12:19





            So, you are saying that _netdev is not meant to be an argument passed to the process which performs mount (and which is specific to the type of mount like ext4/btrfs/cifs/fuse) but is meant to be read by other processes/scripts which based upon this flag decide when during the boot process these mounts should be executed. Yes? If so then I suspect this is the reason why this argument starts with underscore so that to differentiate it from other formal arguments.

            – Piotr Dobrogost
            May 12 '16 at 12:19













            Yes. If you pass the _netdev option to the mount command, it will be visible in /proc/mounts but have no other effect.

            – Ferenc Wágner
            May 12 '16 at 14:07





            Yes. If you pass the _netdev option to the mount command, it will be visible in /proc/mounts but have no other effect.

            – Ferenc Wágner
            May 12 '16 at 14:07













            Bonus question; is this documented somewhere?

            – Piotr Dobrogost
            May 12 '16 at 14:41





            Bonus question; is this documented somewhere?

            – Piotr Dobrogost
            May 12 '16 at 14:41




            1




            1





            The mount manual contains: "FILESYSTEM-INDEPENDENT MOUNT OPTIONS — Some of these options are only useful when they appear in the /etc/fstab file." Well, _netdev (documented somewhat later) is a fine example for this.

            – Ferenc Wágner
            May 12 '16 at 15:04







            The mount manual contains: "FILESYSTEM-INDEPENDENT MOUNT OPTIONS — Some of these options are only useful when they appear in the /etc/fstab file." Well, _netdev (documented somewhat later) is a fine example for this.

            – Ferenc Wágner
            May 12 '16 at 15:04






            1




            1





            The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. – bugzilla.redhat.com/show_bug.cgi?id=607309#c4

            – Piotr Dobrogost
            May 23 '16 at 8:01





            The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. – bugzilla.redhat.com/show_bug.cgi?id=607309#c4

            – Piotr Dobrogost
            May 23 '16 at 8:01













            12














            From man systemd.mount for version 231 of systemd:




            Mount units referring to local and network file systems are
            distinguished by their file
            system type specification. In some cases this is not sufficient (for example network block device based mounts, such as
            iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount
            unit a network mount.







            share|improve this answer
























            • Awsome! No idea why this answer hasn't been up-voted yet.

              – Valentin Bajrami
              Mar 7 '17 at 21:53
















            12














            From man systemd.mount for version 231 of systemd:




            Mount units referring to local and network file systems are
            distinguished by their file
            system type specification. In some cases this is not sufficient (for example network block device based mounts, such as
            iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount
            unit a network mount.







            share|improve this answer
























            • Awsome! No idea why this answer hasn't been up-voted yet.

              – Valentin Bajrami
              Mar 7 '17 at 21:53














            12












            12








            12







            From man systemd.mount for version 231 of systemd:




            Mount units referring to local and network file systems are
            distinguished by their file
            system type specification. In some cases this is not sufficient (for example network block device based mounts, such as
            iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount
            unit a network mount.







            share|improve this answer













            From man systemd.mount for version 231 of systemd:




            Mount units referring to local and network file systems are
            distinguished by their file
            system type specification. In some cases this is not sufficient (for example network block device based mounts, such as
            iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount
            unit a network mount.








            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Dec 20 '16 at 16:16









            Piotr DobrogostPiotr Dobrogost

            1,02311533




            1,02311533













            • Awsome! No idea why this answer hasn't been up-voted yet.

              – Valentin Bajrami
              Mar 7 '17 at 21:53



















            • Awsome! No idea why this answer hasn't been up-voted yet.

              – Valentin Bajrami
              Mar 7 '17 at 21:53

















            Awsome! No idea why this answer hasn't been up-voted yet.

            – Valentin Bajrami
            Mar 7 '17 at 21:53





            Awsome! No idea why this answer hasn't been up-voted yet.

            – Valentin Bajrami
            Mar 7 '17 at 21:53











            1














            Upstart/Udev



            For upstart and/or udev based systems this is slightly different.



            It seems udev will still try to mount the NFS filesystems and netfs is a safety net for when that fails.



            Please correct me if I'm wrong. either way, this answer is only relevant for some recent legacy systems (Ubuntu 14.04 LTS, RHEL6).






            share|improve this answer






























              1














              Upstart/Udev



              For upstart and/or udev based systems this is slightly different.



              It seems udev will still try to mount the NFS filesystems and netfs is a safety net for when that fails.



              Please correct me if I'm wrong. either way, this answer is only relevant for some recent legacy systems (Ubuntu 14.04 LTS, RHEL6).






              share|improve this answer




























                1












                1








                1







                Upstart/Udev



                For upstart and/or udev based systems this is slightly different.



                It seems udev will still try to mount the NFS filesystems and netfs is a safety net for when that fails.



                Please correct me if I'm wrong. either way, this answer is only relevant for some recent legacy systems (Ubuntu 14.04 LTS, RHEL6).






                share|improve this answer















                Upstart/Udev



                For upstart and/or udev based systems this is slightly different.



                It seems udev will still try to mount the NFS filesystems and netfs is a safety net for when that fails.



                Please correct me if I'm wrong. either way, this answer is only relevant for some recent legacy systems (Ubuntu 14.04 LTS, RHEL6).







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Dec 14 '15 at 13:07









                Kevdog777

                2,102123259




                2,102123259










                answered Dec 14 '15 at 11:58









                QuattroQuattro

                111




                111






























                    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.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f169697%2fhow-does-netdev-mount-option-in-etc-fstab-work%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

                    How to make a Squid Proxy server?

                    Is this a new Fibonacci Identity?

                    19世紀