When opening \\$Extend\\$Quota:$Q:$INDEX_ALLOCATION
NT_STATUS_INVALID_PARAMETER is returned because
the stream name verification is to strict after
We need to deferr the check for :$DATA to the backend modules.
This branch fixes the problem for me:
The only change that can cause trouble is the mapping change
from EINVAL to NT_STATUS_INVALID_PARAMETER. But I think that's
a better mapping as to NT_STATUS_INVALID_HANDLE. (Samba4 already
maps to INVALID_PARAMETER)
(Some of the patches are also needed in v3-2 and v3-3)
I think this also needs to be in 3.4.1.
have you looked at the code changes already.
The fixed url is:
Shall I pick that one for 3.4.1 or not?
Metze, could you attach the patch, please?
Created attachment 4625 [details]
Patch for v3-4
We also need this in v3-3, but I'm not sure the patches apply there.
Comment on attachment 4625 [details]
Patch for v3-4
As it stands right now, this patch does not apply cleanly against current v3-4-test (I'm using d5098d737). I had assumed this was for 3.4.
I think we should fix this for 3.4.2, the code has changed to much
between v3-4-test and master.
What the status of this bug?
I still get "\\$Extend\\$Quota:$Q:$INDEX_ALLOCATION NT_STATUS_INVALID_PARAMETER" when using smbcquotas on 3.4.3
I haven't looked into how to fix this for v3-3 and v3-4 yet.
It's only fixed in master and v3-5.
*** Bug 6919 has been marked as a duplicate of this bug. ***
Created attachment 5104 [details]
Patch for v3-2 and v3-3
Can someone please test this patch?
Created attachment 5105 [details]
Patch for v3-4
And this one please
A little reminder to a IRC chat:
17:49 < bigon> metze: doesn't seem to work :/
18:01 < bigon> metze: [2009/12/21 18:00:19, 3] smbd/error.c:60(error_packet_set) error packet at
smbd/nttrans.c(467) cmd=162 (SMBntcreateX) NT_STATUS_INVALID_PARAMETER
18:12 -!- kamenim [email@example.com] has quit ["Miranda IM! Smaller, Faster, Easier.
18:18 < metze> bigon: can you add a DEBUG(0,("check_path_syntax_internal: path[%s] stream[%s]\n", path, s));
18:18 < metze> before the return NT_STATUS_INVALID_PARAMETER;
18:20 < metze> we may need FAKE_FILE_NAME_QUOTA_UNIX instead of FAKE_FILE_NAME_QUOTA_WIN32
Created attachment 5115 [details]
log with DEBUG
I also tried with _UNIX instead of _WIN32 but same error :/
I don't know if it's important or not, but in the log file the path says [...]:$QQ:[...] and the error from smbcquotas it says [...]:$Q:[...]
Then we need a network capture
Created attachment 5117 [details]
The file name looks good in the capture.
The $QQ is very strange...
There is a loop into check_path_syntax_internal that rewrite the path maybe the loop exits too early or something
Created attachment 5120 [details]
New patch for v3-4
Can you please test this patch?
I've tested and it seems that the patch is working (tested with smbcquota)
Created attachment 5154 [details]
New patch for v3-3 (and v3-2)
Created attachment 5155 [details]
log with loglevel10
As I've said, I can get the quotas with smbcquotas, but it seems that it doesn't work with windows xp, in the logs I get:
[2010/01/11 14:12:33, 5] smbd/uid.c:353(change_to_user)
change_to_user uid=(0,1287) gid=(0,513)
[2010/01/11 14:12:33, 4] smbd/vfs.c:753(vfs_ChDir)
vfs_ChDir to /home/l-bigonville
[2010/01/11 14:12:33, 10] smbd/nttrans.c:483(reply_ntcreate_and_X)
reply_ntcreate_and_X: flags = 0x16, access_mask = 0x2019f file_attributes = 0x0, share_access = 0x3, create_disposition = 0x1 create_options = 0x0 root_dir_fid = 0x0, fname = $Extend/$Quota:$Q:$INDEX_ALLOCATION
[2010/01/11 14:12:33, 10] smbd/open.c:3366(create_file_default)
create_file: access_mask = 0x2019f file_attributes = 0x0, share_access = 0x3, create_disposition = 0x1 create_options = 0x0 oplock_request = 0x3 root_dir_fid = 0x0, ea_list = 0x(nil), sd = 0x(nil), create_file_flags = 0x1, fname = $Extend/$Quota:$Q:$INDEX_ALLOCATION
[2010/01/11 14:12:33, 5] smbd/fake_file.c:87(is_fake_file)
is_fake_file: [$Extend/$Quota:$Q:$INDEX_ALLOCATION] is a fake file
[2010/01/11 14:12:33, 3] smbd/fake_file.c:116(open_fake_file)
open_fake_file_shared: access_denied to service[l-bigonville] file[$Extend/$Quota:$Q:$INDEX_ALLOCATION] user[l-bigonville]
[2010/01/11 14:12:33, 10] smbd/open.c:3508(create_file_default)
[2010/01/11 14:12:33, 3] smbd/error.c:60(error_packet_set)
error packet at smbd/nttrans.c(541) cmd=162 (SMBntcreateX) NT_STATUS_ACCESS_DENIED
Created attachment 5156 [details]
tcpdump dump with access denied
< metze> bigon: only root can manage quotas
< bigon> metze: mmm are you sure? because with the same user (memeber of domain admin group) on a 3.0.28a I can see (and I guess manage) the quota but not on a 3.0.24 (this is on my production machines)
To be clear the dump comes from a 3.4.3 version not a 3.0.x
Comment on attachment 5120 [details]
New patch for v3-4
This patch is good for 3.4.5. The access denied is a separate issue - this patch should be applied to fix the pathname problem.
Re-assigning to Karolin to get the fix in attachment 5120 [details] included in the next 3.4.x.
It would be nice to have that also in the next v3-3 release...
Pushed to v3-3-test and v3-4-test.
Re-assigning to Metze as I am not sure whether there is still an open task or not.
Thanks for fixing it, I guess I will open a new bug for the fact that only the user root can see quota tab from windows machines
Looks like this is NOT fixed in 3.5 :(
BTW is 09fe57923ab5570aad106b6b82faabe3fcd130fd really needed?
Yes, otherwise you'll always get NT_STATUS_INVALID_PARAMETER
Jeremy, can you find the cause of the failing access check?
Well the patch that has been applied to 3.4 hasn't been applied to 3.5.
For the permission denied with user != root in 3.4 I've opened a different bug (bug #7080)
v3-5 and master have different patches:
s3:smbd: add is_fake_file_path() that takes only the raw path as string
s3:streams: check for :$DATA only in the backend (fix bug #6642)
s3:error_map: make NTSTATUS -> errno -> NTSTATUS mapping consistent for NT_STATUS_INVALID_PARAMETER
This is fixed in 3.5.x, 3.6.x and master