After hours of searching, I discovered that the share name and the share directory cannot be the same (and it's not case-sensitive, either). See this post on serverfault.

So, if I change my share name in smb.conf from:

[Music]

to

[Tunes]

I can both read and write to the share. No other changes to my smb.conf were necessary, and no need to chmod 0777.

This solved my problem:

Windows 10 will try to negotiate SMB3_11, which Samba4 doesn't yet support
except in the current 4.3 release candidate. I suspect for now disabling
SMB2/3 on the Windows 10 client is your best, if not ideal, option.

Instructions for doing.this can be found
here: https://support.microsoft.com/en-us/kb/2696547

https://lists.samba.org/archive/samba/2015-September/193886.html

Further reading:

• MSKB mentioned above: Microsoft support, KB2696547: How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server

for what it is worth, I couldn't access my samba share, maybe you have forgotten to add you username to the samba password group (for lack of beter description phrase)

this is what I did to get mine to work

smbpasswd -a username

after by using nautilus, shared my drive/folder with right-click, sharing, etc.

create your password, and use your username and passsword (which you just entered) to access your samba drive, you can also map this drive in Windows

hope this could help

In my case (Windows 10, ancient Samba 4.2.10 on CentOS 6) what helped was setting the min protocol to SMB2, max protocol to SMB3:

[global]

min protocol = SMB2
max protocol = SMB3

client min protocol = SMB2
client max protocol = SMB3

client ipc min protocol = SMB2
client ipc max protocol = SMB3

server min protocol = SMB2
server max protocol = SMB3

And then connecting the share as a network drive (Explorer -> Home -> Easy access -> Map as drive), putting in the share name (\\1.2.3.4\ShareName), ticking "Connect using different credentials", then Other, and put in username in the format DOMAIN\username.

When trying to get to the share in Explorer, it would never ask for credentials, nor was I able to specify the username with net use \\shareserver\data /user:testuser (got System Error 58).

From your comment:

I forgot to mention that the drive in /media/USBHDD/shares is formatted in NTFS, to be readable on windows. That makes it unable to be changed using chown and chmod, which are both solutions that I've already tried.

I guess you're using ntfs-3g. In this case you should research the following mount options of it: uid,gid,dmask,fmask. First thing you should do is passing uid=MYUSERNAME to whatever mechanism mounts the drive. This will make the filesystem appear as if everything in it belonged to MYUSERNAME.

If you were mounting via fstab, the proper line would look similar to the one in this question (but read my answer there). The path /media/… suggests the drive might be mounted by some sort of automounter; if so, then you should configure its options.

Some parts of my original answer (below) apply to filesystems that support UNIX permissions. With NTFS, instead of chown you should just pass proper uid and gid while mounting.

Original answer:

Your share and objects under it are owned by root and only the owner has write permissions. I'm talking about UNIX permissions in ls -l output, this itself has nothing to do with Samba.

Then Samba forces any valid user (valid users = backups MYUSERNAME root; these are Samba users, not necessarily UNIX users) to be MYUSERNAME (force user = MYUSERNAME) in context of UNIX permissions. This user has no write access.

Possible solutions:

• let MYUSERNAME own everything in the share:

  sudo chown -R MYUSERNAME: /media/USBHDD/share
  

• give every user write access to everything in the share:

  sudo chmod -R +w /media/USBHDD/share
  

• a combination of above, with reduced scope maybe; or a solution that uses group access; now you know what the issue is, so ask yourself what permissions to what asset you want to give to whom.

• force user = root (if possible), but this would be stupid.

Some of these solutions will work better with different create mask and directory mask in Samba configuration. Research and understand their meaning.

Ok, figured it out. It wasn't in my samba settings. The error was actually in how I was "permanently" mounting my samba share.

I was doing:

//192.168.1.11/craig /home/craig/musicServer cifs username=craig,password=MYPASSWORD 0 0

but I needed

//192.168.1.11/craig /home/craig/musicServer cifs username=craig,password=MYPASSWORD,file_mode=0777,dir_mode=0777 0 0 

Adding both file_mode and dir_mode solved it.

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 problem is not the Samba share but a new security setting under Windows 10. They specifically made it so that you cannot bypass this behaviour from the Samba side. They explain why under the section Cause.

Symptoms

In Windows 10, Windows Server 2019, or Windows Server 2016, the SMB2 client no longer allows the following actions:

• Guest account access to a remote server.
• Fall back to the Guest account after invalid credentials are provided.

SMBv2 has the following behavior in these versions of Windows:

• Windows 10 Enterprise and Windows 10 Education no longer allow a user to connect to a remote share by using guest credentials by default, even if the remote server requests guest credentials.
• Windows Server 2016 Datacenter and Standard editions no longer allow a user to connect to a remote share by using guest credentials by default, even if the remote server requests guest credentials.
• Windows 10 Home and Professional editions are unchanged from their previous default behavior.

If you try to connect to devices that request credentials of a guest instead of appropriate authenticated principals, you may receive the following error message:

You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.

and

Cause

This change in default behavior is by design and is recommended by Microsoft for security.

A malicious computer that impersonates a legitimate file server could allow users to connect as guests without their knowledge. Microsoft recommends that you do not change this default setting. If a remote device is configured to use guest credentials, an administrator should disable guest access to that remote device and configure correct authentication and authorization.

Windows and Windows Server have not enabled guest access or allowed remote users to connect as guest or anonymous users since Windows 2000. Only third-party remote devices might require guest access by default. Microsoft-provided operating systems do not.

and

Resolution

If you want to enable insecure guest access, you can configure the following Group Policy settings:

• Open the Local Group Policy Editor (gpedit.msc).
• In the console tree, select Computer Configuration > Administrative Templates > Network > Lanman Workstation.
• For the setting, right-click Enable insecure guest logons and select Edit.
• Select Enabled and select OK.

Source

https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/guest-access-in-smb2-is-disabled-by-default

For Fedora 25, I am not familiar with fedora version numbers but I am with RHEL/Centos 7.x If you have selinux enabled by default, you might try as root setenforce 0 to temporarily put selinux into permissive mode until next reboot, see if this allows samba access to work. If so then it's a selinux problem, and in RHEL/Centos there is etc/samba/smb.conf.example which explains the samba related selinux commands needed to allow samba shares to work with selinux set to enforcing.

For your version of fedora, I would work off the /etc/samba/smb.conf.example.

for reference here is my working smb.conf from an older version of samba showing what i believe is the minimum required to get it to work. If you go too restrictive with settings then you can prevent a successful connection so sometimes it's best to not specify which generally means allow for all.

In your [myshare] take out allow hosts and valid users. Once samba working then consider adding restrictive measures like these as necessary.

[global]
#       min protocol = SMB1 needed for winxp
        min protocol = SMB1
#       max protocol SMB2 needed to work with win10, unspecified for this older version of samba is smb1.
        max protocol = SMB2 
        security = user
        passdb backend = tdbsam
#       map to guest = never prevents popup option, bad user allows popup in windows
        map to guest = Bad User

[data]
    path = /data
    read only = No
#   guest ok = no
#   create mask = 660
#   directory mask = 770

with guest ok = no, and map to guest bad user, will allow popup in windows giving anyone a chance to enter correct linux username and pw. map to guest never prevents popup, meaning the username of the windows user has to be the same as a valid local user in linux, per security=user. You likely do not need min/max protocol specified, I do in samba version 3.6. I don't know what verion of samba u have in fedora 25, if it's samba 3.x then try specifying the min/max protocol.

don't forget to do smbpasswd -a <username on your linux system.

Your config does not make sense, since "public and "protected" files are using the same user. Use "valid users" to enlist those that are allowed. These users must exist on your samba server:

pbedit -a -u guest

smbpasswd must be empty for "public" if you want to have free access.

For your protected files enlist those users, that may have access to those shares. Add those users via pbeditwith a password. But these instructions can be found here

Solved! The problem was that selinux was not giving samba the necessary permissions to export shares. This fixed it.

 setsebool -P -V samba_export_all_rw=on samba_export_all_rw=on

This solution may be specific to Centos or RHEL 8. Also if you want to allow users to mount home directories there's another bool for that.

Looks like you created a folder miguel in the media and you have taken ownership of it. Instead, let's create a group, add users to that group, and set the permissions.

sudo groupadd -g 10000 [samba_group]
sudo adduser migeul [samba_group]
sudo chown root:[samba_group] -R /media/migeul
sudo chgrp [samba_group] /media/migeul
sudo chmod 775 -R /media/migeul

This will create a group and attach it to the folder to be shared. You add the users to that group for access. Set the permissions to 775 which gives the owner and the group read-write-execute access while others only read. Set's it recursively.

Verify that you have total access to the folder. With samba, setting the permissions are a little bit different than file permissions with a ubuntu user. What I mean is that verify the permissions after you take ownership because they could result in a samba error later on down the road. Where nobody can access the drive.

Create a samba account that matches your Linux username precisely.

sudo smbpasswd -a miguel
sudo smbpasswd -e migeul

That will prompt you to create a password for the username miguel. Please note that this is only for SMB shares not for the user in the Operating System.

Afterward, open up the samba config and when sharing the drive make sure you type in writable = yes, browsable = yes, read only = no and add your group to it as well. Also, verify the location you are sharing from. Use the place that it is mounted to.

[migeul]
comment = Migeuls folder
​path = /media/migeul
​browsable = yes
​writable = yes
​guest ok = no
​read only = no
​valid users = @[samba_group]

After you reconfig the /etc/samba/smb.conf file, reload it.

sudo smbd reload

These pages go more in-depth with setting up samba shares.

https://help.ubuntu.com/community/Samba/SambaServerGuide https://www.techrepublic.com/article/how-to-set-up-samba-shares-for-groups/

You may also need to set your umask as well. To do that open up /etc/profile using sudo nano /etc/profile and at the bottom type in umask 002. Use Control+O to save and Control+X to exit. Best to reboot the server using sudo reboot and the new mask permissions will take place. That setting re-asserts the same permissions for the users.