Description of problem: From ancient times through fedora 15 the attached smb.conf file allowed me to have full read/write access to my /zooty/public shared directory from all my windows machines. Now in fedora 16, I get access denied errors if I attempt to delete a file on the share while running in the windows machine (this happens on both Windows XP and Windows 7 systems). I have been through the smb.conf man page with a fine tooth comb, looking up every option I have set in my smb.conf file, and they all appear to be correct and should allow me write access. Version-Release number of selected component (if applicable): samba-3.6.1-74.fc16.x86_64 How reproducible: Every time Steps to Reproduce: 1.enable smb service 2.connect to network filesystem on windows 3.try to delete a file Actual results: access denied Expected results: file deletion Additional info:
Created attachment 534104 [details] smb.conf file
It acts like it isn't running as "tom" even though that is the user I told it to run as for guest access. If I chmod the directory owned by "tom" to 777 rather than 755, then I can delete files from the Windows side.
It gets more mysterious. If I create a new file from the windows side and look at it on linux, is is indeed owned by tom: drwxrwxrwx 2 tom users 4096 Nov 17 06:15 ./ drwxr-xr-x 9 tom users 4096 Jun 12 07:02 ../ -rwxr--r-- 1 tom users 172 Nov 17 06:15 testing.doc* So why can't I modify the directory which is also owned by tom unless I change it to 777?
'security = share' This option is deprecated as it is incompatible with SMB2. You should use 'security = user'. Normally you use permissions and ACLs to give permissions to a share.
There isn't a single shred of documentation in the smb.conf man page or the samba.org web site saying that security=share no longer works, and there is no message in the log files complaining about it either. How the heck do I use security=user without being forced to provide a password to connect the share inside the windows machine?
You should use security = user and 'map to guest' if you want to mainly setup shares without a password (guest shares).
OK, I found the probable culprit: If I add the following parameter, everything is back to working again with the guest user: acl check permissions = false My guess: The server is doing the ACL checks as the samba server user, not as the guest user. P.S. I still can't find any example of a samba config setup that uses 'map to guest' which doesn't require the window's user to go through an annoying extra login prompt (though I can find examples which will make any password work, it still does the annoying prompt :-).
Probably: map to guest = bad user guest account = tom [myshare] guest ok = true