Technical Anshu
Tutorials Blog
Ubuntu Linux Guide

Mount Windows Share in Ubuntu Permanently With Fstab

You connect to the Windows share, it works all day, and after a reboot it is gone. This page makes the mount permanent the safe way - one careful line in /etc/fstab, your password in a locked-down credentials file instead of plain text, and the two options that stop a switched-off Windows PC from hanging your boot.

Technical AnshuUbuntu and WindowsStep-by-step guide
Watch the video for the complete process shown live, step-by-step

A share you open from the Files app is a session mount: it lives until you log out or reboot, and then Ubuntu politely forgets it. For a folder you use every day - office documents on the Windows PC, a media library, a backup target - that is the wrong tool. The permanent answer is an entry in /etc/fstab, the same file Ubuntu reads at every boot for its own disks. This page builds that entry step by step: the facts to collect, the cifs-utils package, the mount point, the credentials file that keeps your password out of plain sight, the fstab line itself with every option explained, and the test that proves it works before you ever reboot. Server name, share name and user in the examples are placeholders - use your own.

Terminal - the four facts this setup needs (example values)
Windows PC nameOFFICE-PC
Shared folder nameSharedDocs
Share address//OFFICE-PC/SharedDocs
Windows user nameanshu
Mount point in Ubuntu/mnt/SharedDocs
✓ The share opens fine from the Files app first - the network side is proven before fstab is touched
Example values only. Your PC name, share name and user name will be different - everything in this guide is built from these four facts plus your Windows password.
1

Step 1 - Collect the Four Facts Before Touching Anything

Every failed mount in this series traces back to a wrong fact typed confidently into a file. On the Windows PC, note the exact PC name (Settings, System, About), the exact share name - which is the name you gave under Advanced Sharing, not the folder's path - and the user name and password of the Windows account that has permission for the share. Then prove the network side works: in Ubuntu's Files app, use Other Locations, Connect to Server, and open smb://OFFICE-PC/SharedDocs. If it opens there, your remaining work is pure configuration, not troubleshooting.

  1. PC name and share name are case-insensitive but spelling-exact - write them down, do not retype from memory
  2. The account must have a password. Windows blocks network sign-in for accounts with blank passwords by default
  3. If you sign in to Windows with a Microsoft account, the share still wants the account's user name and password, not the PIN
2

Step 2 - Install cifs-utils So Ubuntu Can Speak SMB

Ubuntu cannot mount a Windows share out of the box on a minimal install. The tool that does it is mount.cifs, and it lives in the cifs-utils package. Without it you get confusing errors about a missing helper or a bad filesystem type, and people waste an hour suspecting the network.

  1. Refresh the package list: sudo apt update
  2. Install the package: sudo apt install cifs-utils
  3. That is the only software this whole guide needs. Everything else is configuration files
3

Step 3 - Create the Mount Point, an Empty Folder With a Job

A mount point is just an empty folder that becomes a window onto the share. When the mount succeeds, the folder's contents ARE the share's contents. Convention puts shared mounts in /mnt.

  1. Create it: sudo mkdir -p /mnt/SharedDocs
  2. Leave it empty. Anything you copy into it before mounting is not deleted, just hidden behind the share while the mount is active - a classic source of where-did-my-file-go panic
  3. Use the same name as the share if you like - it makes the fstab line in Step 5 easy to read and audit later
4

Step 4 - Store the Password in a Credentials File, Never in Fstab

This is the step most guides skip, and it is the one that matters most. /etc/fstab is readable by every user account on the machine - anyone can run cat /etc/fstab and read whatever is in it. Putting password=... in that line hands your Windows password to every login on the PC. The standard fix is a separate file only root can read.

  1. Make a backup of fstab first, before any editing today: sudo cp /etc/fstab /etc/fstab.bak
  2. Create the credentials file: sudo nano /root/.smbcredentials
  3. Type exactly two lines: username=anshu and on the next line password=YourWindowsPassword - no spaces around the equals sign
  4. Save, then lock it down: sudo chmod 600 /root/.smbcredentials. The 600 means only root can read or write it
  5. Check it: sudo ls -l /root/.smbcredentials should start with -rw-------

Honest limit: 600 stops other user accounts. It does not stop root, and it does not stop someone holding your unencrypted disk. It removes the password from the one file everybody reads casually - that is the right, standard layer for this job.

5

Step 5 - Add the Fstab Line, Option by Option

Open the file with sudo nano /etc/fstab and add this line at the end, with your own server, share and numbers:

  1. //OFFICE-PC/SharedDocs /mnt/SharedDocs cifs credentials=/root/.smbcredentials,iocharset=utf8,_netdev,nofail,uid=1000,gid=1000 0 0
  2. credentials= points at the locked file from Step 4 - no password appears in fstab itself
  3. _netdev tells systemd this mount needs the network, so it waits for networking instead of failing in the first seconds of boot
  4. nofail means: if the Windows PC is off or unreachable, boot normally anyway and skip the share. Without it, a sleeping office PC can stall your login for over a minute or drop you into emergency mode
  5. uid=1000,gid=1000 makes the files appear owned by you instead of root, so your apps can save normally. Your numbers come from the id command - the first user on Ubuntu is almost always 1000
  6. iocharset=utf8 keeps file names with non-English characters correct, and the trailing 0 0 simply says no dump, no boot-time disk check for this mount
6

Step 6 - Test With mount -a Before You Ever Reboot

Never let a reboot be the first test of an fstab edit - a bad line is much easier to fix from a working terminal. Modern Ubuntu also keeps a generated copy of the mounts, so refresh it first.

  1. Run sudo systemctl daemon-reload so the fstab change is picked up
  2. Run sudo mount -a - this mounts everything in fstab that is not mounted yet, using exactly the line you wrote
  3. No output usually means success. Confirm with ls /mnt/SharedDocs - you should see the Windows files, and df -h /mnt/SharedDocs should show the share and its real size
  4. Create a test file inside it from Ubuntu, then check on the Windows PC that it really arrived - proof in both directions
  5. Only now reboot, and confirm the share is simply there, with no connecting step from you
🔴 Respect fstab - it is a boot file. One wrong character can stop Ubuntu booting normally. That is why Step 4 starts with a backup copy and Step 6 tests with mount -a first: mount -a reports the same errors a boot would hit, while you still have a working terminal to fix them in.

Watch the Complete Video Guide

The full permanent setup shown live - collecting the share details, the credentials file, the fstab line and the reboot test, step-by-step.

Watch Full Video
Common Questions (FAQ)

Why does my share disappear after every reboot?

Because connecting from the Files app or a one-off terminal command creates a session mount - it belongs to your login, not to the system. Only an entry in /etc/fstab (or an automount unit) is recreated by the system itself at boot or on first access. The fstab line on this page is what turns a daily reconnect ritual into a folder that is simply always there.

Is it safe to put my Windows password directly in the fstab line?

No. /etc/fstab is readable by every user account on the machine, so a password written there is effectively public on that PC. The credentials file used on this page is owned by root with 600 permissions, so only root can read it, and fstab itself contains no secret at all - just a pointer to that file.

The mount worked once, but now mount -a gives an error. What changed?

Mounts rarely break on their own - something on one side changed. The usual suspects are in this series: the Windows password was changed so the credentials file is stale, the files suddenly belong to root because uid and gid are missing, or the error is really permission denied from the Windows side. Each has its own page here with the exact check order.

This guide is based on the Technical Anshu video on mounting a Windows share in Ubuntu - stuck on any step, ask in the video comments and you will get an answer.