Samba has its own layer of access control for each share. There are two basic options

• read only: by default every share is read-only, regardless of filesystem permissions,
• writeable: in order to allow write access you should set writeable = Yes.

This should be enough to solve the problem. But if you'd like to learn more about Samba permissions, like how to set umask, enable guest account or control access for individual users/groups, then read the short tutorial on Samba permissions.

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

Considering "non-root through Samba", especially in new releases of OpenSuse (...15.3 -- 15.4), I do few movements into normal configuration panels (no sudo commands or anything technical).

Using Yast Firewall section -- For now (immediate solution):
I turn off the firewall, then see what you can turn on (after this) to keep the samba working with Microsoft Windows.

More details on how to do this with images on my website.

Note: I'm just guessing here, I'm not a samba guru.

Samba/CIFS, at least the way you're using it here, does not reproduce credentials between the server and the client. Because of the force user directive on the server, all operations are performed as the user erpm on the server. However, because both the client and the server are running a unix system, they auto-negociated the CIFS POSIX extensions. This makes unix permissions appear to work up to a point, but only as far as the server permits, and you've run into a case where what the unix permissions claim and what the server allows differ.

You'll notice that all files appear as user ID 501. That's their uid on the server.

When you try to create or remove a file, this requires write permission on the directory. All access are mapped to a single user on the server, so write permission boils down to whether erpm is allowed to write to that directory on the server. The answer is yes.

When you run touch, it creates the file and then changes its modification time. Changing the modification time of a file requires ownership, and this is tested by the generic filesystem code, on the client side.

If you run strace touch test, you'll notice that then open call (which creates the file) succeeds, then the utimes call (or rather on Linux the utimensat system call) fails to set the times.

This is actually a bit weird because utimes should succeed, since touch calls it with a NULL argument (meaning “set the timestamp to the current time”), and this is supposed to be permitted to any caller that may write to the file, and not only to the owner like setting an arbitrary timestamp. I suspect that utimensat is actually doing a permissions-based check, and determining that the permissions say you can't write to that file, even though the filesystem would allow a write operation regardless of the actual permissions.

The main advantage of the CIFS POSIX extensions when the server side is running with the permissions of a non-root user are to carry over the executable bit, and possibly group ownership. It may be less confusing if you map user ownership to a single client-side user with the forceuid mount option.

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

I recommend to create a dedicated user for that share and specify it in force user(see docs).

Create a user (shareuser for example) and set the owner of everything in the share folder to that user:

adduser --system shareuser
chown -R shareuser /path/to/share

Then add force user and permission mask settings in smb.conf:

[myshare]
path = /path/to/share
writeable = yes
browseable = yes
public = yes
create mask = 0644
directory mask = 0755
force user = shareuser

Note that guest ok is a synonym for public.

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.

Is SELinux active? If it is, then you can make it accessible by setting the type to public_content_t. If samba should be able to write to it, then set the type to public_content_rw_t. Note that if you do the latter, you will also need to tell SELinux about this; my system-config-selinux has a boolean for this: Allow Samba to write files in directories labeled public_content_rw_t