I've added a line to /etc/fstab to automatically mount a Windows share on boot. I have tested it using sudo mount -a and the mount shows up correctly and I'm able to access it as expected. However, when I actually reboot, the mount does not work. There aren't any error messages during boot; it seems to simply fail silently.

What could the problem be? The only thing I know is that it takes several seconds beyond the command prompt showing up before my wifi connects, so it seems possible that it's failing because of that. If that is so, how can I make it connect automatically once the wifi becomes available?


6 Answers 6


Mounts in fstab that aren't ready (wifi) will fail and be skipped, as you are seeing.

There are at least three solutions designed to handle this scenario:

The first is to use the old and venerable autofs which was designed for just this sort of problem. There are many ways to configure autofs for mounting network shares, from hard-coded location mapping to dynamic "network neighborhood" type solutions. Check your distribution (Raspbian, Arch, Fedora) for approaches/idioms. Christopher Hill documented a very flexible approach on his blog here: Automounting Windows Shares. You can also read about it on the Arch and Debian sites.

Where autofs is designed specifically to handle automatically mounting filesystems, systemd is a more generalized system that takes actions based on events and mounting and unmounting filesystems based on network visibility/availability is certainly one such example. As of February 2014, Debian has elected systemd as the default init system, so this approach will be preferred as systemd becomes integrated with Debian/Raspbian or, if you are already using systemd, you may prefer this approach to autofs.

The final approach I would only recommend if the previous two won't work for some reason is to use the netsmbfs fuse automounting. This approach results in significantly worse performance than the kernel based solutions. The Arch wiki samba page speaks to this approach.


I was having this problem too (unable to mount Windows shares at boot). I found an option in the Raspberry Pi Configuration tool that fixed my problem.

1) Start X Windows (startx from terminal shell). 2) Click "Menu" button 3) Select Preferences->Raspberry Pi Configuration 4) Select the System tab 5) There is an option called "Network at Boot". Check the "Wait for network" box and click "OK".

Note: you still have to have a proper /etc/fstab entry for the Windows share.


If you can mount it with sudo mount -a, you might be able to add this line to be executed at system start (for example to the ~/.bash_profile, which is executed after login).

To wait for the wi-fi, try this thread at askubuntu.com.
Here is the script from that link (if it became broken for some reason):


while true; do
    # testing...
    LC_ALL=C nmcli -t -f DEVICE,STATE dev | grep -q "^wlan0:connected$"
    if [ $? -eq 0 ]; then
        # not connected, sleeping for a second
        sleep 1

# now connected, run the script

You could also use a different program than nmcli and grep the result in a similar way, if you feel like it...


I was having the same trouble with my Pi - I could run "sudo mount -a" and the CIFS shares would mount normally from the entries in /etc/fstab, but when I restarted, the shares would not mount on boot.

I checked dmesg and saw some socket errors and figured the network wasn't up, but I couldn't get the shares to mount after the network came up. I found a ton of similar threads and tried each of the suggestions, including -

  • adding various parameters to the fstab entry (_netdev, users, nosers, nosuid, the list goes on, but none seemed to help)
  • adding scripts to /etc/network/if-up.d/ and a post-up entry in /etc/network/interfaces, again, didn't help, same error
  • I started trying autofs, but abandoned that as it seemed overly complex, and my initial attempts at set up failed

The suggestion to add a script to ~/.bash_profile helped me when I realized I didn't have nmcli installed - basically, I had to install the network-manager package.

I ran "sudo apt-get update" and then "sudo apt-get install network-manager" and then rebooted the Pi.

Success! The shares were mounted!

My guess is that some of the network timing dependent functions in the OS use network-manager in one way or another. Either way, I hope this helps someone, as I was unable to get my Pi to mount CIFS shares at boot, which seemed basic enough.

  • Could you post an entry from your /etc/fstab? I installed the network-manager, but it's still not working without any additional workarounds (see my response to the original question)...
    – Matthias
    Commented Jan 3, 2016 at 22:17

Same for me - running dmesg showed that the shares were mounted before the network was available, and thus the mounts failed.

What did work in the end for me was using a solution found in [SOLVED] - Cannot automount Samba share from fstab: Adding auto,x-systemd.automount to the entries.

My mounts now look like this:

// /shares/share cifs auto,x-systemd.automount,user,uid=pi,gid=users,rw,suid,credentials=/etc/cifspwd,iocharset=utf8,_netdev 0 0

However, I have no idea what that code is doing, why it works or whether it is a good idea to use it.

  • Didn't work for me on Raspbian Jessie. Because my (wired) network interface is apparently not available when fstab is loaded, this caused my boot to hang waiting for it.
    – Tim
    Commented Mar 31, 2016 at 16:02

I ran into the exact same issue. Here's how I solved it (what I would call the simplest solution):

Running Raspbian-Jessie, after booting into PIXEL, Select the 'Start' menu->Preferences->Raspberry Pi Configuration

Next to the Network at Boot: check the "Wait for Network" box.

This solved the issue for me, as Raspbian will wait for a network connection before mounting the drives in fstab.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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