I use my QNAP as backup stations and this for 99% of operations I mount its shares under my Windows. Once, for some non-typical backup operation, I had to do something exactly opposite — mount remote Windows share under QNAP. Since I’m quite Linux newbie, I had to wrote this down for future reference.
Before you start, create a directory that will work as mount point to your Windows share:
If you search the Internet with query like this post title, you may find many wrong (outdated?) solutions that doesn’t work on QNAP
mount -t smbfs -o username=user,password=pass //192.168.1.11/Files /share/win
and end with for example:
mount: wrong fs type, bad option, bad superblock on //192.168.1.11/Files, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so
Finally I found this guide, which explained that
smbfs is outdated and
cifs should be used instead. So correct command would be:
mount -t cifs //192.168.1.11/Files -o username=vivek,password=myPassword /share/win
This works fine, with a small problem. You have now R/W (full) access from your QNAP to your Windows share, even though you (probably) provided wrong username and password! I have no bloody idea, how can this be? And how isn’t that a strong vioation of security? But the facts are brutal — someone inside your network can gain a full access to my files only, if he or she knows the IP address and Windows share name?
I’ve checked that it doesn’t work without username and password:
mount -t cifs //192.168.1.11/Files /share/win mount -t cifs //192.168.1.4/Backup /backup/remote/win
resulting with above mentioned error message. But works fine with any username and any password!
To unmount such share, use umount command with either your mount point or destination Windows share:
umount /share/win umount //192.168.1.11/Files
Only make sure that you’re not inside it (in any session) or you can get “device is busy” error. If you left that share and still can unmount it, use either
umount -f (force) or
umount -l (lazy) method.