Discussion:
cthon failure
Steve French
2014-08-20 02:33:12 UTC
Permalink
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
Pavel Shilovsky
2014-08-20 06:05:47 UTC
Permalink
Post by 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)?
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.
Pavel Shilovsky
2014-08-20 06:23:36 UTC
Permalink
Post by Pavel Shilovsky
Post by 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)?
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.
Jeremy Allison
2014-08-21 18:55:13 UTC
Permalink
Post by 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)?
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.
Jeremy Allison
2014-08-21 21:13:38 UTC
Permalink
Post by 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)?
Can't reproduce this on current v4-1-test
git branch.

Can you give me details please ?

Jeremy.
Steve French
2014-08-26 00:05:53 UTC
Permalink
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
Post by Jeremy Allison
Post by 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)?
Can't reproduce this on current v4-1-test
git branch.
Can you give me details please ?
Jeremy.
--
Thanks,

Steve
Jeremy Allison
2014-08-26 00:10:33 UTC
Permalink
Post by 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)
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.
Steve French
2014-08-26 02:04:21 UTC
Permalink
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
Post by Jeremy Allison
Post by 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)
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
Jeremy Allison
2014-08-26 16:12:46 UTC
Permalink
Post by Steve French
I can create a bug but the problem is pretty straightforward
Why can't I reproduce it ?
Post by Steve French
[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.

Loading...