Dominik Strasser | 1 Jan 16:07 2007
Picon

Can't mount NAS device

Hi,
I am desperately trying to mount my newly acquired NAS device in Linux 
2.6.18 (OpenSuse 10.2) using cifs.
Unfortunately it doesn't work. I've searched with google and found that  
several people experience the same problem. According to what I've found 
on the net, the device seems not to be 100% cifs compatible. But as 
usual, it works under Windows XP (and CE).

The device is an inexpensive NAS case which can be equipped with an IDE 
disc.

I've turned on CIFS debugging and recorded the attached during a mount.

Can you help? I tried to do some experiments playing with the command 
length which seems to be off, but apart from hangs I didn't produce 
anything usable.

Regards

Dominik

Jan  1 15:51:25 VDR kernel:  /usr/src/linux-2.6.18.2-34/fs/cifs/cifsfs.c: Devname:
//192.168.178.28/Video flags: 0 
Jan  1 15:51:25 VDR kernel:  /usr/src/linux-2.6.18.2-34/fs/cifs/connect.c: CIFS VFS: in cifs_mount as
Xid: 3 with uid: 0
Jan  1 15:51:25 VDR kernel:  /usr/src/linux-2.6.18.2-34/fs/cifs/connect.c: Username: guest 
Jan  1 15:51:25 VDR kernel:  /usr/src/linux-2.6.18.2-34/fs/cifs/connect.c: UNC:
\\192.168.178.28\Video ip: 192.168.178.28\Video
(Continue reading)

Mark Buechler | 2 Jan 20:44 2007
Picon

Re: CIFS client leaving cifs???? files

Ok, after a bit more research and information from another investigator of this I've found out that in order for open files to get deleted the client (cifs fs in this case) needs to set DELETE_ON_CLOSE when opening the file. This is only available when using also using CIFS_XATTR and CIFS_POSIX and ea support enabled on the server side. Given I have all of these enabled, I'm still curious as to why these files are hanging around instead of getting deleted as they should.

If anyone has any ideas or suggestions I would very much appreciate them.

Thanks, Mark.

On 12/20/06, Mark Buechler < mark.buechler <at> gmail.com> wrote:
So, I take it this is by design?

- Mark.


On 12/18/06, Jeremy Allison < jra <at> samba.org> wrote:
On Mon, Dec 18, 2006 at 03:24:28PM -0500, Mark Buechler wrote:
> I'm running samba v3.0.23c and the latest cifs kernel module on my cifs
> client. I'm mounting my samba share on my client with "-o direct". I'm
> seeing something odd with regard to unlinking open files. I run MythTV. When
> Myth deletes a recording, rather than doing a straight unlink it does the
> following:
>
> 1. Open file
> 2. Gradually truncate the file
> 3. When the file gets below a certain file size, unlink it
> 4. Close file
>
> This behavior has a side effect of leaving the truncated files hanging
> around but renamed as cifs??? files. Ie:

Hmmm. Steve - how about using the CIFS UNIX call SMB_SET_FILE_UNIX_BASIC
(trans2 call info level 0x200) with a st_nlink count of zero and a
file type of UNIX_TYPE_FILE (0) to unlink a file ? That way would
work for open files without having to invent a new UNIX_unlink
call ? Currently st_nlink of zero is used in a "special" way
to do mknod calls so there is precedence for this ?

What do you think ?

Jeremy.


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Steve French | 3 Jan 15:44 2007
Picon

Re: CIFS client leaving cifs???? files

> this I've found out that in order for open files to get deleted the client
> (cifs fs in this case) needs to set DELETE_ON_CLOSE when opening the file.
> This is only available when using also using CIFS_XATTR and CIFS_POSIX and
> ea support enabled on the server side.

Use by the client of the delete on close flag does not seem to be related
to CIFS_XATTR or CIFS_POSIX.   See below excerpt from the cifs
delete code in fs/cifs/inode.c

        rc = CIFSSMBDelFile(xid, pTcon, full_path, cifs_sb->local_nls,
                        cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR);

        if (!rc) {
                if (direntry->d_inode)
                        drop_nlink(direntry->d_inode);
        } else if (rc == -ENOENT) {
                d_drop(direntry);
        } else if (rc == -ETXTBSY) {
                int oplock = FALSE;
                __u16 netfid;

                rc = CIFSSMBOpen(xid, pTcon, full_path, FILE_OPEN, DELETE,
                                 CREATE_NOT_DIR | CREATE_DELETE_ON_CLOSE,
                                 &netfid, &oplock, NULL, cifs_sb->local_nls,
                                 cifs_sb->mnt_cifs_flags &
                                        CIFS_MOUNT_MAP_SPECIAL_CHR);
                if (rc==0) {
                        CIFSSMBRenameOpenFile(xid, pTcon, netfid, NULL,
                                              cifs_sb->local_nls,
                                              cifs_sb->mnt_cifs_flags &
                                                CIFS_MOUNT_MAP_SPECIAL_CHR);

CIFS attempts to delete the file, then if that fails, cifs opens it with the
CREATE_DELETE_ON_CLOSE flag and then renames the file (to null apparently)
then closes it.   This seems to work - and I just confirmed it by opening
a file (even putting a write lock on it) with cifs to Samba 3.0.24pre
Maybe this fails on older servers? or when the Unix Extensions are turned
off?

jra,
Doesn't setting "CREATE_DELETE_ON_CLOSE" work to Samba?  I don't remmeber this path being
a problem.

> > > 1. Open file
> > > 2. Gradually truncate the file
> > > 3. When the file gets below a certain file size, unlink it
> > > 4. Close file
> > >
> > > This behavior has a side effect of leaving the truncated files hanging
> > > around but renamed as cifs??? files. Ie:

> >
> > Hmmm. Steve - how about using the CIFS UNIX call SMB_SET_FILE_UNIX_BASIC
> > (trans2 call info level 0x200) with a st_nlink count of zero and a
> > file type of UNIX_TYPE_FILE (0) to unlink a file ? That way would
> > work for open files without having to invent a new UNIX_unlink
> > call ? Currently st_nlink of zero is used in a "special" way
> > to do mknod calls so there is precedence for this ?
Mark Buechler | 3 Jan 16:06 2007
Picon

Re: CIFS client leaving cifs???? files

The attribute DELETE_ON_CLOSE is listed under under the v1 cifs spec found at: http://ubiqx.org/cifs/rfc-draft/draft-leach-cifs-v1-spec-02.html under the heading "3.11  Extended File Attribute Encoding" and at http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf under " 3.13. Extended File Attribute Encoding". My version of Samba is 3.0.23c. Could there be a compile time option I'm missing? I'm running the standard debian compiled version. Attached is the output of "smbd -b".

- Mark.

On 1/3/07, Steve French <smfltc <at> us.ibm.com> wrote:
> this I've found out that in order for open files to get deleted the client
> (cifs fs in this case) needs to set DELETE_ON_CLOSE when opening the file.
> This is only available when using also using CIFS_XATTR and CIFS_POSIX and
> ea support enabled on the server side.

Use by the client of the delete on close flag does not seem to be related
to CIFS_XATTR or CIFS_POSIX.   See below excerpt from the cifs
delete code in fs/cifs/inode.c

        rc = CIFSSMBDelFile(xid, pTcon, full_path, cifs_sb->local_nls,
                        cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR);

        if (!rc) {
                if (direntry->d_inode)
                        drop_nlink(direntry->d_inode);
        } else if (rc == -ENOENT) {
                d_drop(direntry);
        } else if (rc == -ETXTBSY) {
                int oplock = FALSE;
                __u16 netfid;

                rc = CIFSSMBOpen(xid, pTcon, full_path, FILE_OPEN, DELETE,
                                 CREATE_NOT_DIR | CREATE_DELETE_ON_CLOSE,
                                 &netfid, &oplock, NULL, cifs_sb->local_nls,
                                 cifs_sb->mnt_cifs_flags &
                                        CIFS_MOUNT_MAP_SPECIAL_CHR);
                if (rc==0) {
                        CIFSSMBRenameOpenFile(xid, pTcon, netfid, NULL,
                                              cifs_sb->local_nls,
                                              cifs_sb->mnt_cifs_flags &
                                                 CIFS_MOUNT_MAP_SPECIAL_CHR);


CIFS attempts to delete the file, then if that fails, cifs opens it with the
CREATE_DELETE_ON_CLOSE flag and then renames the file (to null apparently)
then closes it.   This seems to work - and I just confirmed it by opening
a file (even putting a write lock on it) with cifs to Samba 3.0.24pre
Maybe this fails on older servers? or when the Unix Extensions are turned
off?

jra,
Doesn't setting "CREATE_DELETE_ON_CLOSE" work to Samba?  I don't remmeber this path being
a problem.


> > > 1. Open file
> > > 2. Gradually truncate the file
> > > 3. When the file gets below a certain file size, unlink it
> > > 4. Close file
> > >
> > > This behavior has a side effect of leaving the truncated files hanging
> > > around but renamed as cifs??? files. Ie:

> >
> > Hmmm. Steve - how about using the CIFS UNIX call SMB_SET_FILE_UNIX_BASIC
> > (trans2 call info level 0x200) with a st_nlink count of zero and a
> > file type of UNIX_TYPE_FILE (0) to unlink a file ? That way would
> > work for open files without having to invent a new UNIX_unlink
> > call ? Currently st_nlink of zero is used in a "special" way
> > to do mknod calls so there is precedence for this ?




Attachment (smbd.out): application/octet-stream, 13 KiB
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Shirish S Pargaonkar | 3 Jan 19:19 2007
Picon

Re: Corrupted data on write to Windows 2003 Server

linux-cifs-client-bounces+shirishp=us.ibm.com <at> lists.samba.org wrote on 12/08/2006 01:24:24 PM:

> When copying a file from linux to windows, I noticed corrupted data
> whenever my data size is larger than about 100-200MB.  I ran a few
> tests, using 'dd', writing a 1GB file with varying block sizes (1, 10,
> 50, 100, and 200 megs).   Each one reported a different md5 when reading
> back.  Only the 200 MB block size was successful, but it may have been a
> fluke... I need to run the test a few more times.
>
> The actual number of bytes in the destination file is correct.  But
> running 'cmp' afterwards, I discovered that the destination ends up
> being 0 padded after a certain point.  The exact spot seems to wander,
> but it appears to be around the 800-900MB mark for these files.
>
> I don't get any error messages or anything from the actual 'dd' command.
>   The only message I get is a kernel message saying: "CIFS VFS: No
> writable handles for inode", which I suppose explains it all.  But it'd
> be nice if the user commands reported some sort of failure.
>
> I don't suppose there are any mount options I can give to cifs to make
> it do more checking or retries or anything?  Or how do I actually
> prevent the "no writable handles" problem?
>
> Of course, if I use rsync, that seems to get around the problem.  But it
> seems kind dumb to have to do that for mounted filesystems. =P
>
>
>
> Linux system: Fedora Core 5
> Linux aeolus.eng.lantronix.com 2.6.18-1.2200.fc5smp #1 SMP Sat Oct 14
> 17:15:35 EDT 2006 i686 i686 i386 GNU/Linux
>
>
> Windows System: Windows Server 2003 R2 Standard w/ SP1
>
> mount options:  cifs (rw,mand)
>
> I don't think this uses samba since cifs is a kernel module, but just in
> case, my samba version is: 3.0.23c
>
> Thanks for any assistance,
> Danny
>
> ---
> Please ignore the following disclaimer, not the message. =)
> **********************************************************************
> This e-mail is the property of Lantronix. It is intended only for
> the person or entity to which it is addressed and may contain
> information that is privileged, confidential, or otherwise protected
> from disclosure. Distribution or copying of this e-mail, or the
> information contained herein, to anyone other than the intended
> recipient is prohibited.
>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client <at> lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client

This patch to cifs.ko should fix the problem, and you do not have to cifs mount with forcedirectio

http://master.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=cb876f451455b6187a7d69de2c112c45ec4b7f99

Regards,

Shirish

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Steve French | 3 Jan 19:44 2007
Picon

Linux CIFS client howto guide

The Linux CIFS client howto/guide has been updated:
   http://svn.samba.org/samba/ftp/cifs-cvs/ols2006-fs-tutorial-smf.pdf
or in OpenOffice format at:
   http://svn.samba.org/samba/ftp/cifs-cvs/linux-cifs-client.odt

Feedback would be welcome.
Steve French (smfltc | 3 Jan 22:26 2007
Picon

Re: Linux CIFS client howto guide

> Ummm, I'm not sure that the "fs-tutorial" pdf link is the link you 
> intended; it looks like a general presentation on Linux file 
> systems... ;-)
>
> On 1/3/07, * Steve French* <smfrench <at> austin.rr.com 
> <mailto:smfrench <at> austin.rr.com>> wrote:
>
>     The Linux CIFS client howto/guide has been updated:
>        
> http://svn.samba.org/samba/ftp/cifs-cvs/ols2006-fs-tutorial-smf.pdf
>     or in OpenOffice format at:
>        http://svn.samba.org/samba/ftp/cifs-cvs/linux-cifs-client.odt
>
>

Sorry about that - it was caused by a cut-and-paste error ...

I renamed them to be consistent so that will harder to do in the future.
Stéfano Schotten | 3 Jan 22:30 2007
Picon

CIFS, Samba 3.0.23d and file locking

Mrs.;

I have a 16-bits Cobol program running at Novell 5.1.

I'm migrating the whole network (around 150 terminais) to Linux + LTS processing DOSEMU into cluster and
making a storage server just for data.

My surprise last week was that the smbfs client for Linux doesn't support the file locking, after googling,
found that a solution would be to use CIFS instead SMB and upgrading the Samba version for 3.0.23D.

Ok, kernel patched (2.4.33.3), CIFS working, Samba upgraded and running.

Now, when I map the share in data storage it is rightly mapped, using the command (from samba 3.0.23d compilation):

mount.cifs //10.1.15.105/data /data -o username=test,password=test

When I run the Cobol program (that mounted using smbfs works fine - just don't lock the files, like windows
client do correctly) it freezes right after open the first screen, in syslog I get the log:

kernel:  CIFS VFS: Error unlocking previously locked range -37 during test of lock last message repeated 30 times

Tried to start the mouting with the nolock option but that's not recognized.

My system:
Slackware 11.0
Intel Dual Xeon 3.0 i386
Kernel 2.4.33.3
Samba Version 3.0.23D
Kernel CIFS built-in compiled (patch 1.20, from samba.org)

[]s
Juergen Pfennig | 4 Jan 21:08 2007
Picon

CIFS renaming problem with KMail and dot files

Hi,
with debian etch kernel 2.6.18 and samba 3.0.23d using kde 3.3.5 

(1) kMail (via cifs unix-extensions-enabled share) produces strange
    files where the filename starts with "cifs" or ".cifs" followed
    by a decimal number. This is reproduceable.
(2) Under rare circumstances such files may be created with other
    software. I have no idea how to reproduce this.

Could this happen in a client side call like ...

  rename("/data/home/jpf/Profiles/Mail/.trash.index.temp", 
         "/data/home/jpf/Profiles/Mail/.trash.index")

if (a) the target exists and (b) the target is still open? 

Yours
Jürgen

Details ...

The symptom (here an "ls -il /home/jpf/Profiles/Mail" on the server):

41002 drwxr-x--- 7 jpf centauri  520 2007-01-04 20:37 .
11115 drwxrwx--- 6 jpf centauri  224 2006-12-06 17:09 ..
35369 drwx------ 5 jpf centauri  120 2007-01-04 20:37 drafts
25029 -rw-r----- 1 jpf centauri   33 2007-01-04 20:37 .drafts.index
28072 -rw-r----- 1 jpf centauri   33 2007-01-04 20:37 .drafts.index.ids
      ...
36195 drwx------ 5 jpf centauri  120 2007-01-04 20:37 trash
39845 -rw-r----- 1 jpf centauri 1429 2007-01-04 20:37 .trash.index
39843 -rw-r----- 1 jpf centauri   45 2007-01-04 20:37 .trash.index.ids

And after emptying kMails Trash folder ...

41002 drwxr-x--- 7 jpf centauri  544 2007-01-04 20:37 .
11115 drwxrwx--- 6 jpf centauri  224 2006-12-06 17:09 ..
39845 -rw-r----- 1 jpf centauri 1429 2007-01-04 20:37 cifs10d7      <-- HERE !
35369 drwx------ 5 jpf centauri  120 2007-01-04 20:37 drafts
25029 -rw-r----- 1 jpf centauri   33 2007-01-04 20:37 .drafts.index
28072 -rw-r----- 1 jpf centauri   33 2007-01-04 20:37 .drafts.index.ids
      ...
36195 drwx------ 5 jpf centauri  120 2007-01-04 20:37 trash
39844 -rw-r----- 1 jpf centauri   33 2007-01-04 20:37 .trash.index
39843 -rw-r----- 1 jpf centauri   33 2007-01-04 20:37 .trash.index.ids

What kMail does (excerpt from strace) ...

[pid 11022] lstat64("/data/home/jpf/Profiles/Mail/.trash.index.sorted", 
{st_mode=S_IFREG|0640, st_size=1005, ...}) = 0
[pid 11022] lstat64("/data/home/jpf/Profiles/Mail/.trash.index.ids", 
{st_mode=S_IFREG|0640, st_size=161, ...}) = 0
[pid 11022] lstat64("/data/home/jpf/Profiles/Mail/.trash.index", 
{st_mode=S_IFREG|0640, st_size=15937, ...}) = 0
[pid 11022] access("/data/home/jpf/Profiles/Mail/.trash.index", F_OK) = 0
[pid 11022] access("/data/home/jpf/Profiles/Mail/.trash.index.ids", F_OK) = 0
[pid 11022] lstat64("/data/home/jpf/Profiles/Mail/.trash.index.ids", 
{st_mode=S_IFREG|0640, st_size=161, ...}) = 0
[pid 11022] lstat64("/data/home/jpf/Profiles/Mail/.trash.index", 
{st_mode=S_IFREG|0640, st_size=15937, ...}) = 0
[pid 11022] open("/data/home/jpf/Profiles/Mail/.trash.index.ids", O_RDWR|
O_LARGEFILE) = 10
[pid 11022] access("/data/home/jpf/Profiles/Mail/.trash.index", F_OK) = 0
[pid 11022] lstat64("/data/home/jpf/Profiles/Mail/.trash.index", 
{st_mode=S_IFREG|0640, st_size=15937, ...}) = 0
[pid 11022] open("/data/home/jpf/Profiles/Mail/.trash.index", O_RDWR|
O_LARGEFILE) = 15
[pid 11022] utime("/data/home/jpf/Profiles/Mail/.trash.index", NULL) = 0
[pid 11022] utime("/data/home/jpf/Profiles/Mail/.trash.index.ids", NULL) = 0
[pid 11022] open("/data/home/jpf/Profiles/Mail/.trash.index.sorted", O_RDWR|
O_LARGEFILE) = 16
[pid 11022] unlink("/data/home/jpf/Profiles/Mail/.trash.index.sorted") = 0
[pid 11022] unlink("/data/home/jpf/Profiles/Mail/.trash.index.temp") = -1 
ENOENT (No such file or directory)
[pid 11022] open("/data/home/jpf/Profiles/Mail/.trash.index.temp", O_WRONLY|
O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 16
[pid 11022] 
rename("/data/home/jpf/Profiles/Mail/.trash.index.temp",
"/data/home/jpf/Profiles/Mail/.trash.index") 
= 0
[pid 11022] open("/data/home/jpf/Profiles/Mail/.trash.index", O_RDWR|
O_LARGEFILE) = 15
[pid 11022] utime("/data/home/jpf/Profiles/Mail/.trash.index", NULL) = 0
[pid 11022] utime("/data/home/jpf/Profiles/Mail/.trash.index.ids", NULL) = 0
[pid 11022] open("/data/home/jpf/Profiles/Mail/.trash.index.ids", O_RDWR|
O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 16
[pid 11022] truncate64("/data/home/jpf/Profiles/Mail/.trash.index.ids", 33) = 
0
[pid 11022] utime("/data/home/jpf/Profiles/Mail/.trash.index", NULL) = 0
[pid 11022] utime("/data/home/jpf/Profiles/Mail/.trash.index.ids", NULL) = 0
[pid 11022] open("/data/home/jpf/Profiles/Mail/.trash.index.ids", O_RDWR|
O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 10
[pid 11022] truncate64("/data/home/jpf/Profiles/Mail/.trash.index.ids", 33) = 
0

P.S.
I still remember that, some decades ago, MS-Dos Version 3 or 4 crashed when 
renaming open files.  Things do repeat!
Prajjwal Devkota | 10 Jan 12:44 2007

mount.cifs -o sec=krb5 still asks for password

Hi Birger

I am trying to use mount.cifs to mount a share from a server using kerberos too, and it asks for a password.  I came across your post at:
http://lists.samba.org/archive/linux-cifs-client/2006-April/001287.html

I was wondering if you had figured out what went wrong.  If you did, please let me know too.

Thanks,
Prajjwal
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Gmane