The most copied fstab examples on the internet put your Windows password in plain text, in a file every account on the machine can read. The credentials file fixes that in four commands, and it is the way permanent share mounts are supposed to be done.
Search for how to mount a Windows share and half the results will show an fstab line containing password=YourPassword in the open. It works - that is exactly the problem. /etc/fstab has no secrets: any user, any guest session, any program running as any account can read it. If your Windows password is in there, it is not stored, it is published - to everyone who can log in to that PC. The credentials file is the standard answer: the password moves into a file owned by root and readable by root alone, and fstab keeps only a pointer to it. This page builds it, locks it, and proves the lock.
Ubuntu sets /etc/fstab to permissions 644: the owner can write it, everyone else can read it. That is fine for disk definitions and a disaster for secrets. Run cat /etc/fstab from any ordinary account and you will see every line, including any password someone pasted into a mount option. Passwords placed directly in a mount command have a second exposure too - they can appear in shell history and, on some setups, in the process list while the mount runs.
The file lives in root's home, because mounts are performed by root at boot - root must be able to read its own file.
sudo nano /root/.smbcredentialsusername=anshupassword=YourWindowsPassworddomain=WORKGROUPA credentials file with loose permissions is the original problem wearing a new name. The permission change is not decoration; it is the mechanism.
sudo chmod 600 /root/.smbcredentialssudo ls -l /root/.smbcredentials must show -rw------- and owner rootcat /root/.smbcredentials should answer Permission denied. That refusal is the feature workingNow the fstab line swaps its secret for a pointer.
sudo nano /etc/fstab and replace username=anshu,password=... with credentials=/root/.smbcredentials in the options, keeping the rest of the line as the core guide built itsudo systemctl daemon-reload, then sudo umount /mnt/SharedDocs and sudo mount -als /mnt/SharedDocshistory) if a mount command ever contained it, and any notes file you drafted the line inWatch the video for the full permanent setup, including where this credentials file fits into the fstab line.
Watch Full VideoBecause the mount is performed by root during boot, before your home folder is guaranteed to be available - on systems with encrypted home folders it may not be readable at all until you log in. /root is always there, always root-owned, and already protected. A credentials file in your home can also silently break the day home permissions or encryption change.
Yes, when the shares accept the same account - simply point each fstab line at the same file. Use separate files when the accounts differ, for example one for the Windows PC and another for a NAS, so a password change on one device only ever means editing one small file.
Almost always the file's format, not its permissions: a space beside the equals sign, quotes typed around the password, or an invisible trailing space will all make the credentials wrong while looking right. Retype the two lines cleanly in nano, and if you edited the file on Windows at any point, recreate it - Windows line endings have broken many credentials files.