Bug 11877 - Unexpected error overwriting dot-files
Unexpected error overwriting dot-files
Status: RESOLVED INVALID
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
4.2.4
All All
: P5 normal
: ---
Assigned To: Samba QA Contact
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-26 23:34 UTC by John Mulligan
Modified: 2016-04-27 20:30 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Mulligan 2016-04-26 23:34:16 UTC
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
Comment 1 Jeremy Allison 2016-04-27 01:35:44 UTC
Can you check on a local Windows filesystem if a hidden file can be overwritten in the same way as with 4.2.11 ?
Comment 2 Jeremy Allison 2016-04-27 01:49:17 UTC
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.
Comment 3 Jeremy Allison 2016-04-27 01:55:41 UTC
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.
Comment 4 John Mulligan 2016-04-27 20:30:28 UTC
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.