cthon failure

cthon failure

[Steve French]

Noticed that even with Unix Extensions on cifs mount that Samba
refuses to delete a file in this scenario (locally and presumably over
nfs it still works since it is in cthon suite).  This causes
connectathon special tests to fail

touch newfile
chmod 0000 newfile
rm newfile

(works locally but samba rejects)

Samba 4.1 rejects posix unlink (set path info) STATUS_CANNOT_DELETE
then client falls back to SMB unlink which fails.  STATUS_CANNOT_DELETE
then client falls back to a set path info of file info basic which
also fails STATUS_ACCESS_DENIED

Will do quick test with Samba master when build completes - but does
this server unlink bug look familiar (or am I missing an smb.conf that
I have forgotten about)?
-- 
Thanks,

Steve

Re: cthon failure

[Pavel Shilovsky]

2014-08-20 6:33 GMT+04:00 Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Noticed that even with Unix Extensions on cifs mount that Samba
> refuses to delete a file in this scenario (locally and presumably over
> nfs it still works since it is in cthon suite).  This causes
> connectathon special tests to fail
>
> touch newfile
> chmod 0000 newfile
> rm newfile
>
> (works locally but samba rejects)
>
> Samba 4.1 rejects posix unlink (set path info) STATUS_CANNOT_DELETE
> then client falls back to SMB unlink which fails.  STATUS_CANNOT_DELETE
> then client falls back to a set path info of file info basic which
> also fails STATUS_ACCESS_DENIED
>
> Will do quick test with Samba master when build completes - but does
> this server unlink bug look familiar (or am I missing an smb.conf that
> I have forgotten about)?


Steve,

I faced with exactly the same problem during my testing.

This behavior appears after setting

"store dos attributes = Yes"

in smb.conf. Without this option all Cthon tests passes fine.

I am using Samba 4.1.7 version (Ubuntu version from Jelmer's ppa
https://launchpad.net/~jelmer/+archive/ubuntu/samba-backports).

-- 
Best regards,
Pavel Shilovsky.

Re: cthon failure

[Pavel Shilovsky]

2014-08-20 10:05 GMT+04:00 Pavel Shilovsky <piastryyy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 2014-08-20 6:33 GMT+04:00 Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> Noticed that even with Unix Extensions on cifs mount that Samba
>> refuses to delete a file in this scenario (locally and presumably over
>> nfs it still works since it is in cthon suite).  This causes
>> connectathon special tests to fail
>>
>> touch newfile
>> chmod 0000 newfile
>> rm newfile
>>
>> (works locally but samba rejects)
>>
>> Samba 4.1 rejects posix unlink (set path info) STATUS_CANNOT_DELETE
>> then client falls back to SMB unlink which fails.  STATUS_CANNOT_DELETE
>> then client falls back to a set path info of file info basic which
>> also fails STATUS_ACCESS_DENIED
>>
>> Will do quick test with Samba master when build completes - but does
>> this server unlink bug look familiar (or am I missing an smb.conf that
>> I have forgotten about)?
>
>
> Steve,
>
> I faced with exactly the same problem during my testing.
>
> This behavior appears after setting
>
> "store dos attributes = Yes"
>
> in smb.conf. Without this option all Cthon tests passes fine.
>
> I am using Samba 4.1.7 version (Ubuntu version from Jelmer's ppa
> https://launchpad.net/~jelmer/+archive/ubuntu/samba-backports).

Samba-3.6.18 doesn't have the problem.

-- 
Best regards,
Pavel Shilovsky.

Re: cthon failure

[Jeremy Allison]

On Tue, Aug 19, 2014 at 09:33:12PM -0500, Steve French wrote:
> Noticed that even with Unix Extensions on cifs mount that Samba
> refuses to delete a file in this scenario (locally and presumably over
> nfs it still works since it is in cthon suite).  This causes
> connectathon special tests to fail
> 
> touch newfile
> chmod 0000 newfile
> rm newfile
> 
> (works locally but samba rejects)
> 
> Samba 4.1 rejects posix unlink (set path info) STATUS_CANNOT_DELETE
> then client falls back to SMB unlink which fails.  STATUS_CANNOT_DELETE
> then client falls back to a set path info of file info basic which
> also fails STATUS_ACCESS_DENIED
> 
> Will do quick test with Samba master when build completes - but does
> this server unlink bug look familiar (or am I missing an smb.conf that
> I have forgotten about)?

Can you send me the debug level 10 log from your 4.1.x tests (and
also tell me *what* 4.1.x version you're running :-).

Thanks,

Jeremy.

Re: cthon failure

[Jeremy Allison]

On Tue, Aug 19, 2014 at 09:33:12PM -0500, Steve French wrote:
> Noticed that even with Unix Extensions on cifs mount that Samba
> refuses to delete a file in this scenario (locally and presumably over
> nfs it still works since it is in cthon suite).  This causes
> connectathon special tests to fail
> 
> touch newfile
> chmod 0000 newfile
> rm newfile
> 
> (works locally but samba rejects)
> 
> Samba 4.1 rejects posix unlink (set path info) STATUS_CANNOT_DELETE
> then client falls back to SMB unlink which fails.  STATUS_CANNOT_DELETE
> then client falls back to a set path info of file info basic which
> also fails STATUS_ACCESS_DENIED
> 
> Will do quick test with Samba master when build completes - but does
> this server unlink bug look familiar (or am I missing an smb.conf that
> I have forgotten about)?

Can't reproduce this on current v4-1-test
git branch.

Can you give me details please ?

Jeremy.

Re: cthon failure

[Steve French]

I just tried it on recent Samba (from about a week ago) with the same results

Version 4.2.0pre1-GIT-47e7440
and also
Version 4.1.6-Ubuntu

If "store dos attributes = yes" (on by default in Ubuntu) is in smb.conf

then the following fails
mount -t cifs //someserver/someshare /mnt
touch /mnt/newfile1
chmod 0000 /mnt/newfile1
stat /mnt/newfile1   (mode displays as expected)
rm /mnt/newfile1  (fails with access denied)

if the identical scenario is tried with "store dos attributes = no" in
smb.conf then it works
mount -t cifs //someserver/someshare /mnt
touch /mnt/newfile2
chmod 0000 /mnt/newfile2
stat /mnt/newfile2  (mode displays as expected)
rm /mnt/newfile2   (delete works), and also removing the newfile1
created above also works)
rm /mnt/newfile1 (also works)

Details:
posix unlink (set path info) fails with access denied/status cannot
delete, as does subsequent smb delete.   Attempts to clear the
readonly bit also fails with access denied

The chmod 0000 causes Samba server to set the read-only dos attribute
in the failing case

On Thu, Aug 21, 2014 at 4:13 PM, Jeremy Allison <jra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Tue, Aug 19, 2014 at 09:33:12PM -0500, Steve French wrote:
>> Noticed that even with Unix Extensions on cifs mount that Samba
>> refuses to delete a file in this scenario (locally and presumably over
>> nfs it still works since it is in cthon suite).  This causes
>> connectathon special tests to fail
>>
>> touch newfile
>> chmod 0000 newfile
>> rm newfile
>>
>> (works locally but samba rejects)
>>
>> Samba 4.1 rejects posix unlink (set path info) STATUS_CANNOT_DELETE
>> then client falls back to SMB unlink which fails.  STATUS_CANNOT_DELETE
>> then client falls back to a set path info of file info basic which
>> also fails STATUS_ACCESS_DENIED
>>
>> Will do quick test with Samba master when build completes - but does
>> this server unlink bug look familiar (or am I missing an smb.conf that
>> I have forgotten about)?
>
> Can't reproduce this on current v4-1-test
> git branch.
>
> Can you give me details please ?
>
> Jeremy.



-- 
Thanks,

Steve

Re: cthon failure

[Jeremy Allison]

On Mon, Aug 25, 2014 at 07:05:53PM -0500, Steve French wrote:
> I just tried it on recent Samba (from about a week ago) with the same results
> 
> Version 4.2.0pre1-GIT-47e7440
> and also
> Version 4.1.6-Ubuntu
> 
> If "store dos attributes = yes" (on by default in Ubuntu) is in smb.conf
> 
> then the following fails
> mount -t cifs //someserver/someshare /mnt
> touch /mnt/newfile1
> chmod 0000 /mnt/newfile1
> stat /mnt/newfile1   (mode displays as expected)
> rm /mnt/newfile1  (fails with access denied)
> 
> if the identical scenario is tried with "store dos attributes = no" in
> smb.conf then it works
> mount -t cifs //someserver/someshare /mnt
> touch /mnt/newfile2
> chmod 0000 /mnt/newfile2
> stat /mnt/newfile2  (mode displays as expected)
> rm /mnt/newfile2   (delete works), and also removing the newfile1
> created above also works)
> rm /mnt/newfile1 (also works)
> 
> Details:
> posix unlink (set path info) fails with access denied/status cannot
> delete, as does subsequent smb delete.   Attempts to clear the
> readonly bit also fails with access denied
> 
> The chmod 0000 causes Samba server to set the read-only dos attribute
> in the failing case

As I said - can't reproduce here so obviously reporting
the same thing I already used to reproduce isn't going to help :-).

Can you get me YOUR ENTIRE smb.conf, debug level 10 log,
wireshark trace of the activity please.

Log a bug and attach them - easiest way to track.

Re: cthon failure

[Steve French]

I can create a bug but the problem is pretty straightforward

[2014/08/25 14:12:33.849169,  1]
../source3/smbd/file_access.c:191(can_set_delete_on_close)
  can_set_delete_on_close: file newfile1 delete on close flag set but
file attribute is readonly.
[2014/08/25 14:12:33.849188,  5]
../lib/dbwrap/dbwrap.c:146(dbwrap_lock_order_state_destructor)
  release lock order 1 for /usr/local/samba/var/lock/locking.tdb
[2014/08/25 14:12:33.849201,  5]
../lib/dbwrap/dbwrap.c:178(dbwrap_check_lock_order)
  check lock order 1 for /usr/local/samba/var/lock/locking.tdb
[2014/08/25 14:12:33.849243,  5]
../lib/dbwrap/dbwrap.c:146(dbwrap_lock_order_state_destructor)
  release lock order 1 for /usr/local/samba/var/lock/locking.tdb
[2014/08/25 14:12:33.849262,  2] ../source3/smbd/close.c:780(close_normal_file)
  sfrench closed file newfile1 (numopen=0) NT_STATUS_OK
[2014/08/25 14:12:33.849295,  5]
../lib/dbwrap/dbwrap.c:178(dbwrap_check_lock_order)
  check lock order 1 for /usr/local/samba/var/lock/smbXsrv_open_global.tdb
[2014/08/25 14:12:33.849313,  5]
../lib/dbwrap/dbwrap.c:146(dbwrap_lock_order_state_destructor)
  release lock order 1 for /usr/local/samba/var/lock/smbXsrv_open_global.tdb
[2014/08/25 14:12:33.849329,  5] ../source3/smbd/files.c:528(file_free)
  freed files structure 23406 (0 used)
[2014/08/25 14:12:33.849344,  3] ../source3/smbd/error.c:82(error_packet_set)
  NT error packet at ../source3/smbd/trans2.c(8321) cmd=50 (SMBtrans2)
NT_STATUS_CANNOT_DELETE

NTSTATUS can_set_delete_on_close(files_struct *fsp, uint32 dosmode)
{
    /*
     * Only allow delete on close for writable files.
     */

    if ((dosmode & FILE_ATTRIBUTE_READONLY) &&
        !lp_delete_readonly(SNUM(fsp->conn))) {
        DEBUG(1,("can_set_delete_on_close: file %s delete on close "
              "flag set but file attribute is readonly.\n",
              fsp_str_dbg(fsp)));
        return NT_STATUS_CANNOT_DELETE;
    }


Another way to get this to work would be to add

       delete readonly (S)

           This parameter allows readonly files to be deleted. This is not
           normal DOS semantics, but is allowed by UNIX.

           This option may be useful for running applications such as rcs,
           where UNIX file ownership prevents changing file permissions, and
           DOS semantics prevent deletion of a read only file.

           Default: delete readonly = no


On Mon, Aug 25, 2014 at 7:10 PM, Jeremy Allison <jra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Mon, Aug 25, 2014 at 07:05:53PM -0500, Steve French wrote:
>> I just tried it on recent Samba (from about a week ago) with the same results
>>
>> Version 4.2.0pre1-GIT-47e7440
>> and also
>> Version 4.1.6-Ubuntu
>>
>> If "store dos attributes = yes" (on by default in Ubuntu) is in smb.conf
>>
>> then the following fails
>> mount -t cifs //someserver/someshare /mnt
>> touch /mnt/newfile1
>> chmod 0000 /mnt/newfile1
>> stat /mnt/newfile1   (mode displays as expected)
>> rm /mnt/newfile1  (fails with access denied)
>>
>> if the identical scenario is tried with "store dos attributes = no" in
>> smb.conf then it works
>> mount -t cifs //someserver/someshare /mnt
>> touch /mnt/newfile2
>> chmod 0000 /mnt/newfile2
>> stat /mnt/newfile2  (mode displays as expected)
>> rm /mnt/newfile2   (delete works), and also removing the newfile1
>> created above also works)
>> rm /mnt/newfile1 (also works)
>>
>> Details:
>> posix unlink (set path info) fails with access denied/status cannot
>> delete, as does subsequent smb delete.   Attempts to clear the
>> readonly bit also fails with access denied
>>
>> The chmod 0000 causes Samba server to set the read-only dos attribute
>> in the failing case
>
> As I said - can't reproduce here so obviously reporting
> the same thing I already used to reproduce isn't going to help :-).
>
> Can you get me YOUR ENTIRE smb.conf, debug level 10 log,
> wireshark trace of the activity please.
>
> Log a bug and attach them - easiest way to track.



-- 
Thanks,

Steve

Re: cthon failure

[Jeremy Allison]

On Mon, Aug 25, 2014 at 09:04:21PM -0500, Steve French wrote:
> I can create a bug but the problem is pretty straightforward

Why can't I reproduce it ?

> [2014/08/25 14:12:33.849169,  1]
> ../source3/smbd/file_access.c:191(can_set_delete_on_close)
>   can_set_delete_on_close: file newfile1 delete on close flag set but
> file attribute is readonly.

Who is setting the file attribute readonly ? Show
me the entire trace please. Or alternatively, you
could JUST GIVE ME WHAT I ASKED FOR !!!!!

(I'm getting frustrated Steve, because your
refusal to give me the data I'm asking for
is delaying me fixing this - if it's a server
bug).

Is the client code doing it ? If so, then the bug is
in the client - *don't do that*. When talking on a
connection with UNIX extensions why are *any* DOS
attributes getting set ?

Jeremy.