Let's take just the first share as an example - and here I'm correcting the read-only = yes line:

[Fr-data]
path = /free/fr/data
read only = yes
valid users = @global
write list = borhacker
force create mode = 0775
force directory mode = 0775
create mask = 0775
directory mask = 0775

The only user that will gain access to the folder being shared is borhacker. Not becase of the share definition in smb.conf but becase the parent folder only allows that user access. In fact borhacker is the only user that can access any of these shares for the same reason.

This represents the Linux permissions on /free/fr:

drwxrwx--- 15 borhacker borhacker 15 Dec 19 12:39 .

You need to allow users other than borhacker the ability to traverse the /free/fr folder:

sudo chmod 775 /free/fr

A samba share definition cannot override the Linux permissions of the folder being shared or the Linux permissions of the path to that folder

You've got a classic ownership/permissions problem here. You've told SAMBA to allow access to /home/hoster/sharetest only to equah but your underlying filesystem permissions deny access to that user (drwx------ 19 hoster hoster 4096 Sep 8 20:20 /home/hoster).

Allow equah access to the directory and it should be ok

chmod a+x /home/hoster

Or force the access by equah to be performed by hoster

# add to smb.conf share definition
force user = hoster

In general this kind of problem can be diagnosed using log level = 3 and looking in the SAMBA server log files.

To access the samba share, please pay attention to:

1. You had to create a system user with the same username. In this case, please issue the following command: useradd -s /sbin/nologin benjamin
2. If you are using a SELINUX-enabled system (eg: CentOS), try to temporarily disable it issuing setenforce 0

EDIT: as the problem persists, try the following:

1. maybe your Windows host is prepending your username with the wrong domain name. From the Windows machine, try to login using localhost\benjamin as the username
2. issue pdbedit -L and check if user benjamin is listed. If so, set a trivial password (you can change it later) using smbpasswd benjamin
3. if user benjamin is not listed, try to recreate it issuing smbpasswd -a benjamin
4. if it does not work, delete the passwd file (it is named passwd.tdb; for reference, in a CentOS 6.x system it is found under /var/lib/samba/private/). Then, recreate your user issuing smbpasswd -a benjamin
5. if it still not working, try to use the root account issuing smbpasswd -a root and check if you can login using the root user. Note: this is only a try. After having done with it, you must delete root's entry issuing smbpasswd -x root
6. Your last resort is to increase the verbosity of logging and see if you can find clues there. For authentication attempts, edit or add the following line on your smb.conf log level = 2 winbind:5, check the logs with something like tail -f /var/log/samba/log* and try to login.

"The hosts allow or allow hosts parameter is one of the key advantages of Samba. It allows access control of shares on the ip-address level. To allow only specific hosts to access a share, list the hosts, separated by comma's. Allowing entire subnets is done by ending the range with a dot."

Samba doesn't allow access control with this option on layer 2, only layer 3.

If you want to white list mac addresses you'll have to find another option to prevent network traffic from reaching the service.

Or if you reallllllly want to take some time doing this, you might see if its possible to modify the code and recompile.

I also would check if samba still has the big security vulnerability advertised years ago.

The additional tagging or qualifying that was added last time will be left out, but while showering it occurred to me that I forgot some things.

I apologize for this.

Before the rest is touched on lets analyze the response I gave and your setup:

1. If your network setup is not tightly controlling ip leasing and network membership, IP access control will not work.

2. If your samba server is not on the same network segment as the client machines, MAC white listing will not work.

3. If your not authenticating to the server as well, neither of these solutions will work.

4. MAC addresses can be spoofed. Its easier these days. If someone can see what the hardware IDs of your devices, by say sniffing the airways in the case of a wifi lan, once they get the key to connect to your network, or even in the case of a wired one where they can plug in somehow, this will not prevent anyone determined enough from getting into your server.

Now lets consider application.

If you're storing something vital, REALLLLLY heed what I'm saying. If you're just sharing movies or video files, not a big deal.

If you're storing executables and people will be running them, restrict write access or you're gonna have some trouble potentially and make sure these executables come from trusted sources and are not altered.

In general, SMB cannot be hardened if the network setup sucks. If I can just plug my computer into the wall and set a static ip address, or mod my MAC address and the dhcpd assigns a specific IP address, instant access.

Also if the password hashing isn't good, or a challenge isn't being sent and the password is even being even being sent in two-way encrypted form across the network, it is potentially possible to access the server.

Also. Don't trust ANY operating system you have not at the very least built yourself and then do not trust it completely. Don't trust any operating system who's code has not been hardened by people you trust or yourself, and then never completely trust an OS that people you trust have modded, because they may not be trustworthy.

But like I said, consider application and making sure people have to authenticate somehow to some network service to be granted access, and you're probably fine.

About the only way to protect data is to keep it in an isolated physically read only form and keep it in your possession or locked up these days. These are the times we live in where bad people did bad things, and tried to do even worse bad things and create our current mess and now everyone is suffering for their idiocy and the original offenders are laughing in hades, in between their pitchfork enema.

By design /media/$USER ( /media/drwade in this case ) will allow only one user to get past it and that is drwade. You are forcing the user to be "nobody". nobody != drwade so access is denied. Change your force user in the [Anonymous2] share definition to drwade:

force user = drwade

RHEL 7 has SELinux enabled by default, and it will restrict Samba's access to the filesystem. When you create your own Samba share in a custom path like /samba/docs, you must apply suitable SELinux labeling to that path.

If you need the directories accessible by Samba and other services, you should use SELinux context type label public_content_rw_t and set the smbd_anon_write SELinux boolean to allow Samba write access to files and directories in public_content_rw_t contexts with full control of file ownerships:

setsebool -P smbd_anon_write=1
semanage fcontext -a -t public_content_rw_t "/samba/docs(/.*)?"
restorecon -Rv /samba/docs

If you don't plan on accessing /samba/docs through any other service (like httpd or ftpd), you can use samba_share_t context instead, and then you don't need the boolean setting:

semanage fcontext -a -t samba_share_t "/samba/docs(/.*)?"
restorecon -Rv /samba/docs

The semanage fcontext -a... command will add the regular expression that defines the new labeling persistently into SELinux configuration, and restorecon will apply the new labeling to the actual filesystem. You could also use chcon to change SELinux context labels, but then your changes would be lost whenever restorecon was executed (e.g. after restoring a backup). Storing the labeling information into SELinux configuration first ensures it can be restored even if your backup methods are not specifically SELinux aware - as long as the SELinux configuration under /etc is also backed up.

For all the people that didn't read the coments on the original post, Haxiel said:

The man page for smb.conf says that the guest ok = yes option allows clients to connect without a password and with the privileges of the guest account. The default guest account is the 'nobody' user.

The preferred approach in this case would be to create a dedicated user account for this purpose, give it the appropriate permissions on the shared path as per your requirement, and then modify your Samba config to use that account. (Syntax: guest account = ftp).

The Linux file system is hierarchical. If you put a road block anywhere along the path to an object it will prevent anyone access to that object.

On your server the /mnt folder allows everyone to pass but your /mnt/nas folder allows only "myuser" to pass so only that user can get to the /mnt/nas/share folder.

2 possible options:

Change the permissions of /mnt/nas:

sudo chmod o+x /mnt/nas

Or change your share definition for [Home] to make your guest user appear to be "myuser":

[Home]
    create mask = 0777
    guest ok = Yes
    path = /mnt/nas/share
    read only = No
    force user = myuser

Then restart smbd:

sudo service smbd restart

You might want to do this anyway since if the guest user (nobody) adds a file to the share it will be owned by "nobody" and "myuser" will not be able to do anything with it. With "force user = myuser" all files added will be owned by "myuser".