Parameter "write list" has no effect and does not allow file deletion/creation/save on read-only share (see configuration below). Once "read only" on "/data1" share is set to "no", all operations complete successfully. ------------------------------------------------------------- samba config (testparm): ---------------------------------------------------- Load smb config files from /etc/samba/smb.conf Processing section "[printers]" Processing section "[data1]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions [global] server string = Samba Server Version %v security = SHARE passdb backend = tdbsam log level = 2 log file = /var/log/samba/log.%m max log size = 50 wins support = Yes guest ok = Yes hosts allow = 127., 192.168.1., 192.168.2. cups options = raw hide unreadable = Yes [printers] comment = All Printers path = /var/spool/samba printable = Yes browseable = No [data1] path = /data1 write list = alla, @alla ------------------------------------------------------------- file access permissions [ll /data1]: ------------------------------------------------------------- total 32 drwxr-xr-x 3 root root 4096 2008-07-24 10:31 backup drwx------ 2 root root 16384 2008-05-22 14:27 lost+found drwxrwxr-x 8 dimar users 4096 2008-11-10 12:39 movies drwxrwxrwx 2 alla alla 4096 2008-11-16 00:02 public [ll /data1/public] total 0 -rw-rw-r-- 1 alla alla 0 2008-11-15 23:51 junk ------------------------------------------------------------- samba logs: ------------------------------------------------------------- [2008/11/16 00:03:41, 2] auth/auth.c:check_ntlm_password(308) check_ntlm_password: authentication for user [alla] -> [alla] -> [alla] succeeded [2008/11/16 00:03:41, 2] lib/access.c:check_access(406) Allowed connection from __ffff_192.168.1.55 (::ffff:192.168.1.55) [2008/11/16 00:03:41, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [alla] -> [alla] FAILED with error NT_STATUS_WRONG_PASSWORD [2008/11/16 00:03:41, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [nobody] -> [nobody] FAILED with error NT_STATUS_NO_SUCH_USER [2008/11/16 00:03:43, 2] smbd/close.c:close_normal_file(586) alla closed file public/junk (numopen=1) NT_STATUS_OK [2008/11/16 00:15:37, 1] smbd/service.c:close_cnum(1401) __ffff_192.168.1.55 (::ffff:192.168.1.55) closed connection to service data1 [2008/11/16 00:15:38, 2] smbd/server.c:deadtime_fn(1040) Closing idle connection [2008/11/16 00:15:42, 2] lib/access.c:check_access(406) Allowed connection from __ffff_192.168.1.55 (::ffff:192.168.1.55) [2008/11/16 00:15:42, 2] lib/access.c:check_access(406) Allowed connection from __ffff_192.168.1.55 (::ffff:192.168.1.55) [2008/11/16 00:15:42, 2] smbd/reply.c:reply_special(425) netbios connect: name1=HUB name2=KARMA [2008/11/16 00:15:42, 2] smbd/reply.c:reply_special(432) netbios connect: local=hub remote=karma, name type = 0 [2008/11/16 00:15:42, 2] smbd/sesssetup.c:setup_new_vc_session(1363) setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources. [2008/11/16 00:15:42, 2] lib/access.c:check_access(406) Allowed connection from __ffff_192.168.1.55 (::ffff:192.168.1.55) [2008/11/16 00:15:42, 2] auth/auth.c:check_ntlm_password(308) check_ntlm_password: authentication for user [alla] -> [alla] -> [alla] succeeded [2008/11/16 00:15:46, 2] lib/access.c:check_access(406) Allowed connection from __ffff_192.168.1.55 (::ffff:192.168.1.55) [2008/11/16 00:15:46, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [alla] -> [alla] FAILED with error NT_STATUS_WRONG_PASSWORD [2008/11/16 00:15:46, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [nobody] -> [nobody] FAILED with error NT_STATUS_NO_SUCH_USER [2008/11/16 00:15:46, 2] lib/access.c:check_access(406) Allowed connection from __ffff_192.168.1.55 (::ffff:192.168.1.55) [2008/11/16 00:15:46, 2] auth/auth.c:check_ntlm_password(308) check_ntlm_password: authentication for user [alla] -> [alla] -> [alla] succeeded [2008/11/16 00:15:46, 1] smbd/service.c:make_connection_snum(1190) __ffff_192.168.1.55 (::ffff:192.168.1.55) connect to service data1 initially as user alla (uid=1000, gid=1000) (pid 5611) [2008/11/16 00:15:50, 2] smbd/open.c:open_file(407) alla opened file public/junk read=Yes write=No (numopen=2) [2008/11/16 00:15:50, 2] smbd/close.c:close_normal_file(586) alla closed file public/junk (numopen=1) NT_STATUS_OK [2008/11/16 00:15:50, 2] smbd/open.c:open_file(407) alla opened file public/junk read=Yes write=No (numopen=2) [2008/11/16 00:15:50, 2] smbd/close.c:close_normal_file(586) alla closed file public/junk (numopen=1) NT_STATUS_OK [2008/11/16 00:15:50, 2] smbd/open.c:open_file(407) alla opened file public/junk read=Yes write=No (numopen=2) [2008/11/16 00:15:53, 2] smbd/close.c:close_normal_file(586) alla closed file public/junk (numopen=1) NT_STATUS_OK
Hmmmm. When shall we retire "security = share" ? Jeremy.
Please, do not retire it - share security could be very usefull in small networks that do not have a domain controller (expensive option: 24x7 server box + higher maintenance costs).
(In reply to comment #2) > Please, do not retire it - share security could be very usefull in small > networks that do not have a domain controller (expensive option: 24x7 server > box + higher maintenance costs). > You can do the same things with security = user on a standalone Samba box.
No I'm sorry, that's simply not true. There's nothing that share level security does these days that can't be done with user level security other than cause us these pointless and irritating regressions. Jeremy.
Jerry - could you direct me, please, to instructions on how to configure samba file server using security = user. I need the following setup (easy to achieve with security = share or domain): 1. after user logs into his workstation, no further authentication needed with samba server (separate box on the same LAN) to access its shares 2. samba server gives read/write access to known users based on server access lists; unknown users automatically mapped to guest account 3. file access permittions on shares are not maintained (e.g. could be messed up) and should not be relied on. Thank you in advance, Dima
This is a duplicate. I've got a patch for 3.2.x and above, let's track it there. Jeremy. *** This bug has been marked as a duplicate of 1254 ***
What version is this patch for? I tried to apply it to the latest 3.2.4 and it failed with the following message: [samba-3.2.4]$ patch -p1 < share_access.patch patching file source/smbd/share_access.c Hunk #2 FAILED at 248. 1 out of 2 hunks FAILED -- saving rejects to file source/smbd/share_access.c.rej patching file source/smbd/uid.c
Code has probably changed. Check out any of the current Samba git branches (3.2-test, 3.3-test, 3_0_maint or master) and you'll find I've fixed it in all of them. Jeremy.
Bad news - I manually merged the patch into release 3.2.5 and the fix did not work. The error below seems to be the cause: [2008/12/04 16:14:30, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [dimar] -> [dimar] FAILED with error NT_STATUS_WRONG_PASSWORD It sounds odd to me that samba checks ntlm passwords when security mode = SHARE. Shouldn't it use local database instead? Or did I configure it wrong? P.S. Where can I find 3.2-test and other git branches?
security = share only uses Lanman passwords. That's all the client sends, it's a limitation of security=share. Because they're so insecure we don't send them or even generate them in the password database by default. So you'll need to enable lanman passwords and then change the user password to make sure that a lanman password was generated for this account. Then the patch will work for you. Or you could just ditch share level security. Jeremy.
It seems that the problem is not related to client/server password hashing or encryption. When I set forced user to be the one from the write list, then samba should not try to authenticate the client, but I still see "Authentication for user ... FAILED with error NT_STATUS_WRONG_PASSWORD". Dima
You're not understanding how this works. You have to be able to authenticate as a user, before the force user takes over. So no, there's no bug here. You still are not authenticating as the user. Jeremy.
Jeremy, as you suggested, I turned lanman authentication on and then deleted and added my user using pdbedit. This wrong password error is still there. Dima ------------------------------------------------------------------- [2008/12/05 13:38:58, 4] libsmb/ntlm_check.c:ntlm_password_check(328) ntlm_password_check: Checking NT MD4 password [2008/12/05 13:38:58, 4] auth/auth_sam.c:sam_account_ok(137) sam_account_ok: Checking SMB password for user dimar [2008/12/05 13:38:58, 5] auth/auth_sam.c:logon_hours_ok(119) logon_hours_ok: user dimar allowed to logon at this time (Fri Dec 5 18:38:58 2008 ) ....... [2008/12/05 13:38:58, 3] auth/auth.c:check_ntlm_password(269) check_ntlm_password: sam authentication for user [dimar] succeeded ..... [2008/12/05 13:38:58, 5] auth/auth_util.c:make_user_info_for_reply(408) make_user_info_for_reply: User passwords not in encrypted format. ..... [2008/12/05 13:38:58, 3] libsmb/ntlm_check.c:ntlm_password_check(358) ntlm_password_check: NEITHER LanMan nor NT password supplied for user dimar [2008/12/05 13:38:58, 5] auth/auth.c:check_ntlm_password(272) check_ntlm_password: sam authentication for user [dimar] FAILED with error NT_STATUS_WRONG_PASSWORD [2008/12/05 13:38:58, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [dimar] -> [dimar] FAILED with error NT_STATUS_WRONG_PASSWORD
"make_user_info_for_reply: User passwords not in encrypted format." Why is your client not being detected as using encrypted passwords ? Upload a wireshark capture trace and a debug level 10 log. Anyway, this is a different problem to the write list issue, please open another bug on share level security and attach the required details. Jeremy.
Jeremy, thank you for advice - my client was misconfigured causing authentication failure. I fixed that but all write operations were keep failing with errors similar to the following: [2008/12/08 09:30:17, 3] locking/locking.c:fetch_share_mode_unlocked(857) fill_share_mode_lock failed I looked into the code and found that fill_share_mode_lock() fails because fetch_share_mode_unlocked() calls it with last argument = NULL. This will never work in any version 3.2.xxx including the latest git test.
Read the code closer. fill_share_mode_lock() only returns false with the last argument const struct timespec *old_write_time == NULL if lck->fresh = (share_mode_data.dptr == NULL); is true. In other words, if this a new entry, not an existing entry. In the write path there must always be a share mode lock entry to write on an open file, so this is not the cause of your problem. This has severely strayed off the "write list" codepath so I'd suggest you open another bug and attach your debug level 10 log to it. Jeremy.
I am opening another bug on this new matter and when it is fixed I will try to test write lists again. Dima
Should be fixed in Samba 3.2.6. Please re-open if it is still an issue. Thanks for reporting!