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.

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.

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.

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.

Adding both the parameters read only = no as well as writable = yes seems to do the trick.

The whole smb.conf

[global]

security = user
passdb backend = tdbsam
unix charset = utf-8
dos charset = cp932
map to guest = Bad Password

[private-share]
path = /home/pi/music
valid users = @smbgrp
read only = no
writable = yes

On the Mac client, the permissions of the mounted share are not root with group wheel anymore. Instead, the owner now is the logged in Mac user and group staff:

$ ls -l /Volumes/samba-share
drwx------  1 hans  staff  16384  1 Feb 18:05 non-pro

I am able to create folders and files as well as delete and rename folders and files. So finally it works as it should.