Technical Anshu
Tutorials Blog
Ubuntu Basics

Temporary vs Permanent Share Mounts in Ubuntu Which One You Need

Ubuntu gives you three ways to reach the same Windows share, and they are not interchangeable. One is a quick look, one is a working session, and only one is still there after a reboot. Picking the wrong one is why the same share feels reliable for one person and broken for another.

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

Nothing is wrong with your share - you are probably just using a mount that was designed to be temporary. When you connect from the Files app, Ubuntu creates the connection for your login session and tears it down when the session ends. That is correct behaviour for a quick look at a colleague's folder, and completely wrong for the folder your backup runs into every night. There are three levels - Files app, terminal mount, and fstab - and each one survives exactly as long as it was built to. This page puts them side by side so you can choose deliberately instead of by habit.

The three ways to open the same share, compared
Files app connectionENDS AT LOGOUT
Terminal mount commandENDS AT SHUTDOWN
fstab entrySURVIVES REBOOTS
✓ Same share, same files - the only difference is how long the connection is meant to live
The three mount types side by side. If a share keeps vanishing, the mount type - not the share - is almost always the explanation.
1

The Files App Way - Quick, Friendly, Gone Tomorrow

Open Files, choose Other Locations, Connect to Server, and enter smb://OFFICE-PC/SharedDocs. Thirty seconds later you are browsing the share. This is a GVFS mount: it lives inside your desktop session, appears in the Files sidebar, and is perfect for grabbing one file from a machine you rarely touch.

  1. Its honest limits: it is created when you click, not when you log in, so nothing reconnects it automatically
  2. Many programs cannot use its path - it lives under a per-session GVFS address, so a backup tool or a script that expects a normal folder path may simply not see the share
  3. You can bookmark it in Files, but a bookmark is a shortcut to reconnect, not a connection
2

The Terminal Mount - A Real Folder, for This Session

A manual mount gives the share a real folder path that every program can use, but it still dies with the session or shutdown.

  1. Create a folder: sudo mkdir -p /mnt/SharedDocs
  2. Mount it, letting the terminal ask for the password so it never appears in a file: sudo mount -t cifs //OFFICE-PC/SharedDocs /mnt/SharedDocs -o username=anshu
  3. Work with it as a normal folder, then release it when done: sudo umount /mnt/SharedDocs

This is the right tool for one heavy job - a big copy, a script run, a technician session - on a machine where the share should not outlive the task.

3

The Fstab Way - The Only One That Survives a Reboot

A line in /etc/fstab is an instruction to the system itself: mount this share at every boot, whoever logs in. It uses the same mount.cifs as the terminal command, plus a root-only credentials file so the password is never typed or stored in plain sight. The companion core guide in this series builds that line option by option - credentials file, _netdev, nofail, uid and gid - and tests it before any reboot.

  1. Choose fstab when the share is part of daily work, a backup target, or needed by software that runs before you log in
  2. Choose it knowing its cost: the Windows PC becomes part of your boot, which is why the nofail and automount safety options exist
4

So Which One Should You Use - The Honest Decision

Match the mount to the relationship with the machine. A quick look at a folder on a PC you do not own: Files app, every time - a permanent entry on someone else's machine leaves your password file sitting on yours and a dependency you will both forget. A one-off big job: terminal mount, unmounted when finished. Your own office PC and your own Ubuntu machine, used together daily: fstab, set up once, properly, with the credentials file.

  1. The pattern to remember: the longer the mount lives, the more care its password storage deserves
  2. Temporary on a borrowed or shared machine is not a lesser choice - it is the correct, tidy one
🔴 The trap in the middle: leaving a Files app bookmark and expecting programs to find the share. The bookmark reconnects the view in Files - it does not give the system a stable folder path. If any software besides you needs the share, you need a real mount, temporary or permanent.

Watch the Complete Video Guide

Watch the video to see the permanent setup done live, and how it compares with the quick connection you may be using today.

Watch Full Video
Common Questions (FAQ)

Why does the share in the Files app vanish even though I bookmarked it?

A bookmark only remembers where to connect - the connection itself is still made per session, when you click. Nothing in the bookmark asks Ubuntu to reconnect at login, and the GVFS address behind it is created fresh each time. For an always-there folder, only an fstab entry or an automount gives the system that instruction.

Can a manual terminal mount be made to ask for the password every time?

Yes - leaving the password out of the command, as shown on this page, makes mount.cifs prompt for it interactively. Nothing is stored, which suits shared machines. The trade-off is honesty in the other direction: a mount that needs a human to type a password can never be automatic, so scheduled jobs and backups cannot rely on it.

I only need the share inside one program. Which mount is best?

If the program works with normal folder paths, a terminal mount to a folder like /mnt/SharedDocs is the clean fit - real path, no boot changes, gone when you unmount. If the program is a file manager or an app that understands smb:// addresses, the Files app route may be enough. Test with the Files route first; escalate only as far as the job requires.

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.