Bug 3833 - Cannot Access Mounted Windows Share (cifs) via ftp
Summary: Cannot Access Mounted Windows Share (cifs) via ftp
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: x86 Linux
: P3 normal
Target Milestone: ---
Assignee: Steve French
QA Contact:
Depends on:
Reported: 2006-06-13 21:10 UTC by Rai R.
Modified: 2009-03-07 11:17 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Rai R. 2006-06-13 21:10:40 UTC
Connected to linux.domain.com.
220 Welcome to blah FTP service.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (localhost:root): rai
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd windows
250 Directory successfully changed.
ftp> get deltemp.bat
local: deltemp.bat remote: deltemp.bat
227 Entering Passive Mode (127,0,0,1,38,168)
150 Opening BINARY mode data connection for deltemp.bat (51 bytes).
426 Failure writing network stream.

I get this error when I try to download a file from a mounted windows share using CIFS. We are using Windows 2003 Server (fileserver) and FC5 (ftp server).

User can upload files to ftp server but cannot download files from the mounted share.

I mounted the share using this command:

mount -t cifs // /windows -o rw,domain=domain,username=rai,password=rai

Im totally lost. 

Thanks in advance.
Comment 1 shirishpargaonkar@gmail.com 2006-12-08 14:30:04 UTC
Looks like this problem occurs only with both Windows and samba servers.
I tried downloading using ftp a file residing on nfs mounted share
and could download successfully.

To mount samba and Windows XP shares, the same cifs module was used on
the ftp server.

Ethereal trace on the linux box which has mounted Windows XP share (ftp server)
does not show any error during any of smb requests and responses.  

For a ftp Request like this, there are two Responses listed below

Request command: RETR
Request arg: <name_of_the_file>

Response code: File status okay: about to open data connection (150)
Response arg: Opening BINARY mode data connection for <name_of_the_file> (size)

Response code:  Connection closed:  transfer aborted (426)
Response arg: failure writing network stream

Then I see another ftp request and a response

Request code: MDTM
Request arg: <name_of_the_file>

Response code: File status (213)
Response arg: <some_large_14_digit_number>

In case of NFS, the ftp request is NLST instead of RETR.
I do not understand all these two responses and requests by ftp server.

I am using vsftp version 2.0.4-19.2 on the ftp server (SLES10 2.6.26 with
cifs.ko 1.45) and ftp client (SLES9 2.6.5) has version 1.2.1-69.3.

There are no errors in dmesg.  I had turned on cifsFYI.

I believe this is a ftp/vsftp issue and not a cifs problem.
Comment 2 shirishpargaonkar@gmail.com 2006-12-08 14:56:01 UTC
I should add that between ftp request (RETR) and first ftp response,
the cifs messages successfully exchanged between Windows XP server and
ftp server (cifs client) are create_andX_request and 
Query_Path_info (Level of Interest: Query File Unix Basic).

Perhaps vsftp version on ftp client needs to be updated in my case
but either way I do not see a cifs.ko bug here.
Comment 3 shirishpargaonkar@gmail.com 2006-12-09 08:28:17 UTC
In case of NFS mounts, the response to request NLST is 

Response code: File status okay: about to open data connection (150)
Response arg: Here comes the directory listing

And the transaction is completes.

I do not understand why the ftp response differences between the two 
i.e. nfs mounts and cifs mounts.

Comment 4 shirishpargaonkar@gmail.com 2009-02-03 17:45:24 UTC
Is this still a problem?
Comment 5 Steve French 2009-03-07 11:17:01 UTC
Please reopen if you still see this problem