An SMB share can be visible on the network and still reject a user with NT_STATUS_ACCESS_DENIED when one permission layer does not match the action being tested. Treat the failed client operation as the starting signal, because a browse failure, a write failure, and a login failure point at different parts of the Samba stack.
Samba authorizes a connection through the account database, the parsed share definition, and the Linux filesystem path behind the share. A user must authenticate as an enabled Samba account, match any valid users or write list rule, and have the needed execute, read, or write permission on every directory component below the share path.
Run the checks from the server side after reproducing the exact denied action from a client account. Avoid widening permissions until one layer shows the mismatch; on SELinux hosts, a wrong file context can still deny access after Samba and POSIX permissions look correct.
$ printf 'probe\n' > probe.txt
$ smbclient //files.example.net/projects --user=jane -c 'put probe.txt probe.txt' Password for [WORKGROUP\jane]: NT_STATUS_ACCESS_DENIED opening remote file \probe.txt
If the original failure is read access instead of write access, run the matching smbclient action, such as ls, against the same share.
Related: How to browse SMB shares with smbclient
$ sudo pdbedit --user=jane --verbose Unix username: jane NT username: Account Flags: [U ] ##### snipped #####
Account Flags containing D means the Samba account is disabled. Re-enable only the intended user account instead of changing the share permission model.
$ sudo testparm --suppress-prompt --section-name=projects /etc/samba/smb.conf [projects] path = /srv/samba/projects read only = No valid users = jane
read only = Yes blocks writes, and valid users or write list must include the connecting user or a group that contains that user.
$ namei --long /srv/samba/projects f: /srv/samba/projects drwxr-xr-x root root / drwxr-xr-x root root srv drwxr-xr-x root root samba drwxrws--- root projectrw projects
Every parent directory needs execute permission for the mapped Linux user or group. The final directory needs write permission for SMB uploads and changes.
$ getfacl --absolute-names /srv/samba/projects # file: /srv/samba/projects # owner: root # group: projectrw # flags: -s- user::rwx group::rwx other::---
Look for the ACL entry and effective mask that should grant the connecting user or group access.
Related: How to set ACL permissions on a Samba share
$ getenforce Enforcing
If SELinux is enforcing and Samba, share, and POSIX ACL checks all allow the action, inspect the path type with ls -Zd /srv/samba/projects and review audit logs for smbd denials before changing policy. A normal shared data directory usually needs the samba_share_t type; samba_export_all_rw is broader because it allows writable Samba access outside that label.
$ sudo usermod --append --groups projectrw jane
This example fixes a Linux group mismatch found by namei and getfacl. If the mismatch is a share rule, edit /etc/samba/smb.conf and reload Samba instead; if it is an SELinux label, apply the corrected file context and restore it.
$ smbclient //files.example.net/projects --user=jane -c 'put probe.txt probe.txt' Password for [WORKGROUP\jane]: putting file probe.txt as \probe.txt (1.0 kB/s) (average 1.0 kB/s)
Reconnect after account, group, ACL, share, or SELinux changes so the retry does not reuse stale session state.
$ smbclient //files.example.net/projects --user=jane -c 'del probe.txt'
$ rm -f probe.txt