Mounted Share Shows Files Owned by Root The uid and gid Fix
The mount worked. The files are listed. And every single one says root - so your editor opens them read-only, your backup refuses them, and saving your own document onto your own share needs sudo. The share is not broken; Ubuntu is presenting it with the wrong owner, and two options fix it.
Technical AnshuUbuntu and WindowsStep-by-step guide
Watch the video for the complete process shown live, step-by-step
Here is the fact that makes this behaviour make sense: Windows shares do not carry Linux ownership at all. SMB has no uid, no gid, no Unix permissions to show Ubuntu - so the CIFS mount has to invent an owner to display, and unless you tell it otherwise it invents root, because root is who ran the mount. Every file then wears a root costume. Programs that check ownership before saving quite correctly refuse. The costume is set by two mount options, uid and gid, and setting them to YOU is the entire fix.
Listing the mounted share - before and after (example output)
✓ Nothing on the Windows PC changed - only how Ubuntu presents the files
Example output. Same files, same share - the only thing that moved is the name Ubuntu shows as the owner, which is what your programs check.
1
Step 1 - Understand What the Mount Is Inventing
Because the invention is presentational, two things follow. First, the fix cannot hurt the Windows side - no ACLs are rewritten, no files change, only the local display and the checks your programs make against it. Second, a single mount can present exactly one owner for the whole share, because the invention is uniform. Keep both facts; they explain every behaviour on this page, including the multi-user limit at the end.
Check the current state honestly: ls -l /mnt/SharedDocs and see the wall of root
Notice the mount itself works - this is not a permission problem on the server, and Windows-side fixes will not move it
2
Step 2 - Find Your Real Numbers With the id Command
Do not copy 1000 from a guide and hope. Read your own numbers.
Run: id
The output opens with your numbers, in the style of uid=1000(anshu) gid=1000(anshu)
The first account created on Ubuntu is normally 1000 for both - which is why every example uses it - but a second or third user on the machine will be 1001, 1002, and the mount must match the person who uses the share
3
Step 3 - Add uid and gid to the Fstab Options
The two options join the option list you already have, in the fourth field of the line.
Edit: sudo nano /etc/fstab
The options should now include them, like this: credentials=/root/.smbcredentials,_netdev,nofail,uid=1000,gid=1000 with your numbers from Step 2
Save, then apply: sudo systemctl daemon-reload, sudo umount /mnt/SharedDocs, sudo mount -a
Verify: ls -l /mnt/SharedDocs - the files should now carry your name, and a save from your editor should simply work
4
Step 4 - When Files Still Refuse - the Mode Masks, Honestly Explained
Ownership fixed, an occasional file still shows locked-down permissions. The CIFS mount also invents permission bits, and two more options shape them: file_mode=0664 and dir_mode=0775 present files and folders with those Unix-style modes. Use them when a program complains about modes rather than owners.
Understand what they are: presentation masks on the Ubuntu side, the same family of invention as uid and gid
Understand what they are not: they do not grant real access. If Windows denies a save, no mask on the Ubuntu side can argue - that road leads back to the share and NTFS permissions covered in this series
Add modes only when a symptom calls for them; a share that works with uid and gid alone does not need more options
🔴 One mount, one presented owner - plan for it. On a family or office Ubuntu PC with several logins, an fstab mount will show the files as belonging to the one uid you chose. Other users still reach the share with the access Windows grants, but ownership-sensitive programs may grumble for them. The tidy pattern there is a per-user automount, or accepting one primary user for that share - not five competing fstab lines for the same target.
Watch the Complete Video Guide
Watch the video for the whole permanent mount, including the options that make the share feel like a local folder.
Do uid and gid change anything on the Windows PC or for other people using the share?
No. They only control how Ubuntu presents ownership on this machine. The Windows PC stores and guards the files exactly as before, Windows users see no change, and another Ubuntu machine mounting the same share can present the files under a completely different local user - both are local costumes over the same files.
I added uid and gid but the listing still shows root. What went wrong?
Usually the mount never actually restarted: the old mount stays active with its old options until it is unmounted and remounted, and a plain mount -a skips targets that are already mounted. Unmount first, then mount -a, and confirm the options took with findmnt or mount output. Also check the options sit in the fourth field of the line, comma-separated, with no spaces.
Can two users on this Ubuntu PC each see the share as their own?
Not through one fstab mount - it presents one owner. Each user can have their own mount of the same share to their own folder with their own uid and gid, which is what per-user automount setups do. For a single shared folder used casually, most households simply pick the main user's numbers and move on.
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.