I found the following on the mount man page:
Mount options for smbfs Just like nfs, the smbfs implementation expects a binary argument (a struct smb_mount_data) to the mount system call. This argument is constructed by smbmount(8) and the current version of mount (2.12) does not know anything about smbfs.
Which lead me to the smbmount man page:
WARNING: smbmount is deprecated and not maintained any longer. mount.cifs (mount -t cifs) should be used instead of smbmount.
Which lead me to the mount.cifs man page:
mount.cifs mounts a Linux CIFS filesystem. It is usually invoked indirectly by the mount(8) command when using the "-t cifs" option.
File And Directory Ownership And Permissions The core CIFS protocol does not provide unix ownership information or mode for files and directories. Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. Attempting to change these values via chmod/chown will return success but have no effect.
When the client and server negotiate unix extensions, files and directories will be assigned the uid, gid, and mode provided by the server. Because CIFS mounts are generally single-user, and the same credentials are used no matter what user accesses the mount, newly created files and directories will generally be given ownership corresponding to whatever credentials were used to mount the share.
If the uid's and gid's being used do not match on the client and server, the forceuid and forcegid options may be helpful. Note however, that there is no corresponding option to override the mode. Permissions assigned to a file when forceuid or forcegid are in effect may not reflect the the real permissions.
When unix extensions are not negotiated, it's also possible to emulate them locally on the server using the "dynperm" mount option. When this mount option is in effect, newly created files and directories will receive what appear to be proper permissions. These permissions are not stored on the server however and can disappear at any time in the future (subject to the whims of the kernel flushing out the inode cache). In general, this mount option is discouraged.
It's also possible to override permission checking on the client altogether via the noperm option. Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.
This explains why your attempts to chown don't do anything.
I've never actually mounted or configured an smb share, so I'm kind of guessing, but it seems like the fstab entry should probably look something like this:
//SERVER/sharename /mnt/mountpoint cifs _netdev,username=myuser,password=mypass,uid=xxx,gid=xxx 0 0
Where you populate the uid with your user's ID, and the GID with your user's id. (NOTE that you may need forceuid and forcegid)
The username and password options are used for authentication to the samba share.
Another (and probably the best) option would be to setup a proper usershare:
Arch Wiki - Samba Usershare
