This is possibly a regression in Samba 4.2.8 vs. 4.2.7. It appears to still be present in 4.2.11. It may have been caused by the fix for bug 11645. It appears that when both 'store dos attributes' and 'hide dot files' are set dot files can not be overwritten. In my case 'store dos attributes' is set to yes and 'hide dot files' is enabled by default. My testing uses python in a very simple manner: Using 4.2.7: Python on Windows client: >>> open("Y:/.b.txt", "wb").close() >>> open("Y:/.b.txt", "wb").close() >>> open("Y:/.b.txt", "wb").close() >>> open("Y:/.b.txt", "wb").close() Using 4.2.8 (or later): Python on Windows client: >>> open("Y:/.c.txt", "wb").close() >>> open("Y:/.c.txt", "wb").close() Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 13] Permission denied: 'Y:/.c.txt' Client OS is Windows 8. A filtered version of my smb.conf follows: [global] workgroup = FOREST1 realm = FOREST1.FOOBAR.NET security = ADS password server = qahyperv10 syslog = 0 debug pid = Yes min receivefile size = 131072 load printers = No printcap name = /dev/null disable spoolss = Yes show add printer wizard = No template shell = /sbin/nologin idmap config qa2k8: read only = no idmap config qa2k8: backend = rid idmap config qa2k8: range = 8000100-16000100 idmap config *: read only = yes idmap config *: range = 200000-210000 idmap config forest1: read only = no idmap config forest1: backend = rid idmap config forest1: range = 400000-8000000 idmap config * : backend = tdb force unknown acl user = Yes [test12153] path = /var/foobar/cache/bug12153 read only = No inherit permissions = Yes inherit acls = Yes aio read size = 1 aio write size = 1 map acl inherit = Yes hide unreadable = Yes veto files = /.snapshot/ store dos attributes = Yes delete readonly = Yes dos filemode = Yes When the operation is failing I see the following logging: [2016/04/26 17:29:26.003921, 10, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/open.c:4972(create_file_default) create_file: access_mask = 0x120196 file_attributes = 0x80, share_access = 0x3, create_disposition = 0x5 create_options = 0x40 oplock_request = 0x2 private_flags = 0x0 root_dir_fid = 0x0, ea_list = 0x(nil), sd = 0x(nil), fname = .d.txt [2016/04/26 17:29:26.003944, 10, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/open.c:4449(create_file_unixpath) create_file_unixpath: access_mask = 0x120196 file_attributes = 0x80, share_access = 0x3, create_disposition = 0x5 create_options = 0x40 oplock_request = 0x2 private_flags = 0x0 ea_list = 0x(nil), sd = 0x(nil), fname = .d.txt ... [2016/04/26 17:29:26.005792, 8, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/dosmode.c:36(dos_mode_debug_print) dos_mode returning ha [2016/04/26 17:29:26.005806, 10, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/open.c:2012(open_match_attributes) open_match_attributes: old_dos_attr = 0x22, existing_unx_mode = 0100766, new_dos_attr = 0x0 returned_unx_mode = 00 [2016/04/26 17:29:26.005845, 5, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/open.c:2611(open_file_ntcreate) open_file_ntcreate: attributes missmatch for file .d.txt (22 0) (0100766, 0766) ... [2016/04/26 17:29:26.006331, 10, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/open.c:4793(create_file_unixpath) create_file_unixpath: NT_STATUS_ACCESS_DENIED [2016/04/26 17:29:26.006347, 10, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/open.c:5069(create_file_default) create_file: NT_STATUS_ACCESS_DENIED [2016/04/26 17:29:26.006369, 10, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/smb2_server.c:2706(smbd_smb2_request_error_ex) smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_create.c:293 [2016/04/26 17:29:26.006391, 10, pid=23661, effective(401114, 400512), real(401114, 0)] ../source3/smbd/smb2_server.c:2597(smbd_smb2_request_done_ex) smbd_smb2_request_done_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] body[8] dyn[yes:1] at ../source3/smbd/smb2_server.c:2754
Can you check on a local Windows filesystem if a hidden file can be overwritten in the same way as with 4.2.11 ?
OK, I just tested this on a local filesystem. echo >foo attrib +h foo python >>> open("foo", "wb").close() Traceback(most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 13] Permission denied: 'foo' So this seems to be correct Windows behavior.
I think the bug is one that was fixed by the fix for bug 11645. Prior to that, when both 'store dos attributes' and 'hide dot files' are set then dot files were not being reported as having the HIDDEN attribute.
Yeah you are right, I did think the fix for bug 11645 was related, but I failed to check if Windows behavior matched the new behavior. In my defense I still think that its pretty bizarre behavior that say 'w' for overwrite fails but you can open with 'a' and (then truncate/whatever). Either way Samba matches windows so that not a bug on Samba's part. Sorry for the noise.