When creating a share who can be read by users in the 'valid users' en can be writable by users in the 'write list', any write access from the windows workstation has been denied ! I tried with different settings (see settings below), but nothing works! Please send help! Greetz, Marcel [test1] path=/home/test write list = marcel valid users = @users force user = root [test1] path=/home/test read only = yes write list = marcel valid users = @users force user = root [test1] path=/home/test writable = no write list = marcel valid users = @users force user = root
do you have security = share by chance ?
The problem seems to be that change_to_user() does not call check_user_ok() -> is_share_read_only_for_user() when 'force user' is set.
Ok, I'm assuming the semantics required here are : validate user can read or write. Then change to forced user/forced group and that user or group retains the read or write access that the original accessing user had. This only really makes sense in modes better than security=share I think. Please comment if this understanding is incorrect. Jeremy.
Created attachment 516 [details] Patch for this in modes better than security=share. Patch for this in modes better than security=share. Jeremy.
*** Bug 1369 has been marked as a duplicate of this bug. ***
closing as fixed
Hi, With a share such as that below, this bug is still evident. I patched 3.0.4 source with the patch at: http://samba.org/~jerry/patches/post-3.0.4/samba-3.0.4.patch and the share is still not writable (as it was in 2.x.x) by members of the specs group. I have quite a bit of 'log level = 10' log file I could post if it might help. Let me know the bits you want. Many thanks for Samba and for releasing it under the GPL. Regards, ===Rich [Specs] comment = Specifications valid users = rah ian anne vamp jim ann indra temps ocr sue node14 path = /home/Specifications write list = @specs force group = specs public = yes guest ok = yes force create mode = 775 read only = true force directory mode = 775 hide dot files = yes
reopening for new report.
*** This bug has been marked as a duplicate of 1254 ***