this is a spin-off from the discussion in https://bugzilla.samba.org/show_bug.cgi?id=8083#c18 "inherit owner = yes" doesn't work with directories if "inherit permissions = yes" is being used at the same time. I tested a simple share with inherit acls = yes inherit permissions = yes inherit owner = yes read only = no created files DO inherit the owner of the parent directory but created directories are being owned by the user who created it, which is not intended.
Reproduced this. Just pushed fix for this for master - once it comes back from autobuild I'll attach it for 3.6.0final, and create a version for 3.5.9. Jeremy.
Created attachment 6543 [details] git-am fix for 3.5.9.
Created attachment 6544 [details] git-am fix for 3.6.0 Fix for 3.6.0-final. Bjorn please test these patches (they both work in my testing here) and give approval if they're good. Thanks ! Jeremy.
hm, on a quick test it still doesn't work in my test environment with directories. But the logs have a good hint: [2011/06/08 22:51:52.702757, 0] smbd/open.c:321(change_dir_owner_to_parent) change_dir_owner_to_parent: device/inode/mode on directory sub1/sub2/Neuer Ordner (6) changed. Refusing to chown !
Created attachment 6546 [details] Updated fix for 3.5.9 - fixes issue Bjorn found. Try this - should fix the issue you found - we don't need to be checking the mode bits as well as the dev/ino to ensure we're in the same place.
Created attachment 6547 [details] Updated fix for 3.6.0 final - fixes issue Bjorn found.
Created attachment 6548 [details] git-am fix for 3.5.9 This is what I've pushed to master. Should completely fix all correctness issues around ensuring the returned stat struct in an open fsp is correct.
Created attachment 6549 [details] git-am fix for 3.6.0-final This is what I've pushed to master. Should completely fix all correctness issues around ensuring the returned stat struct in an open fsp is correct.
Comment on attachment 6548 [details] git-am fix for 3.5.9 looks good and finally fixes it for me, thanks a lot!
reassign to Karolin for inclusion in 3.5 and 3.6
Pushed to v3-6-test. Unfortunately, it's too late for 3.5.9. Jeremy, do we need to delay 3.5.9 due to this one?
Hmm - tough call. How long a delay would you need ?
(In reply to comment #12) > Hmm - tough call. How long a delay would you need ? The policy is to freeze the branch one week before a bugfix release. Pushing the patches today would mean to be able to ship on June 16 (instead of June 14). So it's only two days later. If the patches are 100% uncritical, we can discuss if a exception can be done.
(In reply to comment #13) > (In reply to comment #12) > > Hmm - tough call. How long a delay would you need ? > > The policy is to freeze the branch one week before a bugfix release. > Pushing the patches today would mean to be able to ship on June 16 (instead of > June 14). So it's only two days later. > > If the patches are 100% uncritical, we can discuss if a exception can be done. ^^^ an
2 days slip is ok by me. These features just don't work without these patches, and it's something we've had users complaining about in the past. Björn, can you also comment please ?
I would be fine if the patches would not make it into 3.5.9 if that would delay the release. There are enough other fixes that are important enough to get a 3.5.9 out without extra delays. We can point people complaining about this to the patches - binary package providers can decide on their own whether or not to add the patches into their 3.5.9 packages already.
If it's only 2 days, let's just take the hit and ship with the fix included. Doesn't make sense to leave them out IMHO. Jeremy.
(In reply to comment #17) > If it's only 2 days, let's just take the hit and ship with the fix included. > > Doesn't make sense to leave them out IMHO. > > Jeremy. Pushed to v3-5-test. If there are no objections, I will stick to the schedule nevertheless. Closing out bug report. Thanks!
BUG#7638 is a duplicated.
(In reply to comment #19) > BUG#7638 is a duplicated. BUG#7639 is also a duplicated.
*** Bug 7639 has been marked as a duplicate of this bug. ***
*** Bug 7638 has been marked as a duplicate of this bug. ***