Samba share permission denied user writing file but still shows

_{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.