I have added a share in fstab to access a network drive with all my files on... fstab looks like:

proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
// /media/disk1 cifs username=pi,password=raspberry,_netdev,uid=1000,gid=1000,iocharset=utf8, 0 0
# a swapfile is not a swap partition, so no using swapon|off from here on, use dphys-swapfile swap[on|off] for that

When I run sudo mount -a the network drive mounts successfully and I can do cd /media/disk1 then ls which correctly gives me a list of all the folders on said network drive.

However, after rebooting the pi when I cd to that location and run ls again, nothing is there. I have to manually run sudo mount -a again, which then mounts the drive.

I have seen this reported many times on other forums, and the consensus seems to be that the mounts in fstab are happening too early - before the network has been established. I've tried to implement the things I understand - but to be honest a lot of it is way over my head. I've added _netdev to the line in fstab, I've added rootdelay=10 into /boot/cmdline.txt, I've installed networkmanager... none of this has helped.

And so I turn to you, about ready to throw the pi out the window - followed by myself. Any help, much appreciated.

8 Answers 8


I suggest you add the mount to either the root or your user crontab.

Given that you are currently using sudo the root crontab appears to be the most appropriate.

sudo crontab -e # to edit the root crontab

Add a @reboot entry to the crontab. You need a line such as

@reboot (sleep 30; /bin/mount /media/disk1)&

That'll wait for 30 seconds before mounting the disk.

  • 1
    Apologies for the time taken to get to this, I've only just had a chance to play around with this again. I'm very relieved to say your solution worked perfectly. Thank you very much for your help. Commented Aug 25, 2015 at 19:58
  • this mounts for sure but how do we unmount procedurally on shutdown ? Commented Aug 20, 2016 at 18:06
  • Even though this might work, it's not the best engineering solution for the problem, since you make assumptions on timing that it takes to mount your devices (why 30? does 10 work? or 5?). I'd suggest anyone looking for a definitive answer to look at the most voted answer with making RPi wait for network on boot, so that regular /etc/fstabworks properly.
    – tyron
    Commented Feb 28, 2021 at 21:32

I also had the same issue regarding auto-mounting a network drive at boot. I tried adding mount -a command in the /etc/rc.local after editing the /etc/fstab but to no avail. The reason it doesn't work is that the network is not ready before the mount -a is executed.

As others have mentioned the issue is that fstab drives are mounted even before the network is up. In order to be sure that the network is ready during the boot, there is an option Wait for Network at Boot in raspi-config.


sudo raspi-config

and set the Wait for Network at Boot option to Slow wait for network connection before completing boot and reboot. Of course the boot up time may well be affected but if that's not critical, this method can be used.

After the reboot you can check that the network drive is mounted automatically: quick check through ls /media/DRIVE_NAME or df

  • This is certainly the fix that worked for me, With rpi3 latest updates as of November 2016
    – ChrisAdmin
    Commented Oct 31, 2016 at 4:57
  • I prefer to use the /etc/rc.local mount -a solution, but don't forget to sleep first. See my answer I just posted here: raspberrypi.stackexchange.com/a/63690/49091 Commented Mar 21, 2017 at 3:20
  • This was the fix for me, with a Raspberry Pi 4 as of January 2023
    – BlissSol
    Commented Jan 3, 2023 at 8:30

Update notes, seeing that this came up on Google. I suffered the same series of frustrations mounting my Airport Time Capsule. I am running Raspberry Pi 3B+ on Rasbian Stretch released 14 March 2018 with standard GUI.

Here is my fstab code line:

// /mnt/timecapsule cifs username=********, password=******, vers=1.0, rw, uid=1000, iocharset=utf8, sec=ntlm 0 0

A few changes appear to have happened over time:

  1. You need to add "vers=1.0" statement
  2. _netdev does nothing on CFIS file system, only works on NFS file system (as noted by Gabriel Staples below)
  3. "user=" and "pass=" should now be "username=" and "password=" respectively
  4. Lastly, there is now a "Wait for network" box that that can be ticked in the Raspberry Pi Configuration Utility, that solved my mount at boot problem.

After 2 days of struggles, mine is now finally mounted and does so at boot !


You can add the _netdev and comment=systemd.automount attributes in the fstab and it is all working fine for me upon reboot. I used to face the same problem on reboot.

\\network_shared_location\directory /your_mount_location/mount_directory cifs _netdev,username=<your_username>,password=<your_password>,workgroup=<YOUR_WORKGROUP>,users,auto,user_xattr,comment=systemd.automount 0 0
  • 1
    this is the only thing that worked for me on Debian Buster 10.5. I'd triple upvote you for how useful this comment turned out to be, thank you.
    – nxet
    Commented Sep 14, 2020 at 16:47
  • 1
    I have 2 debian 11 bullseye, one of the two wasn't able to mount cifs partition on boot, comment=systemd.automount solved for me too, but the strange thing is that the other same server didn't need it
    – lese
    Commented Jan 27, 2022 at 13:46
  • Had the same issue in Proxmox, fixed it for me, thanks a lot!
    – knipp
    Commented Dec 13, 2023 at 19:11

Another trick to solve this issue is to append in the bottom of file /etc/rc.local the command:

mount -a

After reboot you can verify if it's all ok by typing the command:

df -h

and you'll see something like this:

pi@raspberrypi ~ $ df -h
File system      Dim. Usati Dispon. Uso% Montato su
/dev/root        7,2G  6,3G    584M  92% /
devtmpfs         119M     0    119M   0% /dev
tmpfs             25M  412K     25M   2% /run
tmpfs            5,0M     0    5,0M   0% /run/lock
tmpfs             49M     0     49M   0% /run/shm
/dev/mmcblk0p1    56M   20M     37M  36% /boot
// 466G  452G     14G  98% /mnt/winshare  <----------

In my case I bought a Raspberry Pi 3 and installed Raspbian Stretch, I edited my fstab with my favorite arrangement of network drives like this:

// /mnt/share/Z cifs  username=frieza,password=meh,uid=1000,gid=1000,vers=2.0 0 0
// /mnt/share/V cifs  username=goku,password=meh,uid=1000,gid=1000,vers=2.0 0 0
// /mnt/share/M cifs  username=piccolo,password=meh,uid=1000,gid=1000,vers=2.0 0 0
// /mnt/share/O cifs  username=drbrief,password=meh,uid=1000,gid=1000,vers=2.0 0 0
// /mnt/share/R cifs  username=vegeta,password=meh,uid=1000,gid=1000,vers=2.0 0 0

So whenever I used:

sudo mount -a

Every drive listed in fstab would mount automatically, then I added this to rc.local and several other places so that I could enjoy the content of these drives upon startup, long story short, nothing worked until I decided to add a line to the root crontab like by:

sudo crontab -e

Chose my editor (nano in y case) Then added this line at the bottom

@reboot (sleep 20;/bin/mount -a)&

Everything worked fine in my case after rebooting. Hope this helps you guys out.


If you run into any issues, you can always run:

service cron status

And it will give you a hint on what ran and what didn't


The _netdev option in /etc/fstab doesn't seem to do anything at all for cifs shares. This resource (https://help.ubuntu.com/community/Fstab) seems to confirm that when it says "_netdev - this is a network device, mount it after bringing up the network. Only valid with fstype nfs".

I prefer using the /etc/rc.local file to fix this, by sleeping and then calling mount -a within it, rather than using crontab or the Wait for network at boot option in raspi-config. However, to get the /etc/rc.local fix to work, don't forget to sleep, as explained below.

What I have done to fix this problem (on my Pi3) is modify /etc/rc.local to sleep 20 seconds (by calling sleep 20) and then call mount -a. This way, even though the network is NOT connected yet when the system first reads the fstab file, so the mount fails then, I force the system to wait 20 seconds here (giving the network time to connect) then I force it to call mount -a again to mount all drives in the fstab file.

Here is what my /etc/rc.local file now looks like:

#!/bin/sh -e
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.

# Print the IP address
#GS notes: a *minimum* of sleep 10 is required for the mount below to work on the Pi 3; it failed with sleep 5, but worked with sleep 10, sleep 15, and sleep 30
sleep 20
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
  mount -a #GS: mount all drives in /etc/fstab

exit 0

Done! It now works perfectly for me!


  1. [my answer] https://askubuntu.com/a/895124/327339
  2. https://www.raspberrypi.org/documentation/linux/usage/rc-local.md
  3. http://elinux.org/RPi_Email_IP_On_Boot_Debian - they have a similar rc.local file with a comment in it that says:
    # Print the IP address if it doesn't work ad sleep 30 before all your code

I know this is a little late reply but I had the same problem and it was to do with the network not being up when the fstab was called. I tried the crontab first and it worked ok but thought was a bit messy...

There is a great post here which runs through using a script in init.d to run the mount as on boot... it is working great for me now.

  • 1
    Can you edit your answer to provide the salient details from your link, in case of future link death. Commented Sep 16, 2015 at 20:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.