Bug 2673 - Can create a file. Cannot rewrite it.
Can create a file. Cannot rewrite it.
Status: CLOSED FIXED
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
All Linux
: P3 major
: ---
Assigned To: Steve French
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-30 10:03 UTC by Eric Valette
Modified: 2009-03-25 15:30 UTC (History)
4 users (show)

See Also:


Attachments
failing command after a echo 1 > traceSMB (15.16 KB, text/plain)
2005-11-15 03:18 UTC, Eric Valette
no flags Details
small test program to do strace (145 bytes, text/plain)
2005-11-21 10:04 UTC, Eric Valette
no flags Details
The EACESS error in strace (1.69 KB, text/plain)
2005-11-21 10:06 UTC, Eric Valette
no flags Details
The dmesg after the echo 1 > ... DebugData (15.00 KB, text/plain)
2005-11-21 10:07 UTC, Eric Valette
no flags Details
ethereal captures (5.61 KB, application/octet-stream)
2006-05-23 05:46 UTC, Sebastian Voitzsch
no flags Details
map O_TRUNC correctly to FILE_OVERWRITE (i.e., SMBOPEN_OTRUNC) instead of SMBOPEN_OAPPEND (393 bytes, patch)
2006-05-23 10:00 UTC, Sebastian Voitzsch
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Valette 2005-04-30 10:03:16 UTC
OS : Linux 2.6.12-rc2
Distrib : debian sid (+ ubuntu Xorg 6.8;2 + kde 3.4).

I work for a large french company that use and abuse windows for all cleints.
Everything shared and backuped is on windows shares (2003 servers if I remember
correctly). I progressively switched all clients to open source ones
(thunderbird, firefox, openoffice, gaim, ...) and once evrything worked I tooks
the plunge on Linux.

After using CIFS file system mounted explicitely using my windows user account,
I can see everything on the network share and it mostly works. However, I still
have two very annoying bugs :
        1) Under thunderbird, when I create a new local subfolder on a shared
disk (that create a directory and a file), thunderbird behaves strangely. The
new subfolder does not appear. If I close and restart, i see the subfoledr but
cannot drag mail into it,
        2) When I save an attachement in thunderbird or a file in open office, I
can create the new file on the CIFS mounted files but cannot overwrite them (e.g
save them twices in a row),

Apart that, I can share my mails on windows and linux and everything would be
perfect without thoses two bugs.

Questions : 
         1) are this known bugs?
         2) I have seen the 1.34 release and can patch my kernel. Is there any
chance that the bugs are already fixed? I've seen things in Linus git changelog
for cifs lately but cannot find explicitely something related execpt maybe the
caching problem.
Comment 1 Eric Valette 2005-05-02 01:30:10 UTC
I tested with 1.34 source code : no change. I then looked at ls -l in the 
directory and saw everything belonging to root.root with rw-r--r-- for the file 
that cause problem. I then looked at mount.cifs source code and saw that the 
name searched by 1.7 to get the user id in the credential filed is "username" 
when the man page installed on sid for mount.cifs says "user". The mount.cifs 
version installed on sid system is 1.6 and the associated man page says "user". 
 
If I use mount.cifs 1.7 + username in the credential file, thing seems to work 
better as I can now overwrite the file and the permission aloso differ : 
-rwxrwSrwt. 
 
My next set of questions is therefore : 
        1) did the code for getting the user id change between 1.6 and 1.7. If 
no I will open a bug on debian for the man page, 
        2) could other things have changed that could explain the behavior 
beyond this "user" ->"username" mistake 
 
Comment 2 Steve French 2005-05-03 11:36:42 UTC
The current man pages list the syntax correctly, the credential file requires
"username" (not "user").  The original thinking was probably to allow credential
files for smbfs to be used by both.  See
http://us1.samba.org/samba/docs/man/mount.cifs.8.html
Comment 3 Steve French 2005-05-03 11:38:41 UTC
The only credential file processing code that I can think of that changed
recently (probably post 1.7 version of the mount.cifs mount helper) was adding
support for the "domain=" parm in credential files.

go ahead and reopen this if the correct credential file syntax did not resolve
your problem.
Comment 4 Eric Valette 2005-05-04 12:06:14 UTC
I checked the syntax of /etc/fstab and credential files. They are ok as far as I
can tell (I'm home).

I did a simple test :

mkdir test
cd test
cat > toto
abc 
^d
cat > toto
=> permission denied.

The toto file is viewed via ls -l as rw-r--r root.root so it is correct. The
root.root is suspect but I guess there is no other solution to display accounts
with other permission than Unix ones.

the mount point (from memory) is created using :
credentials=/home/login/.sambaCredendentials, domain=FTRD, rw

and the credential files contains :

username=<my FTRD domain login>
password=<my FTRD domain pasword>

I think the server is running WINT 5 aka windows 2000 server.

Comment 5 Eric Valette 2005-08-09 02:18:26 UTC
Here are some more information about this bug. It is a problem with credential
used when creating a file using CIFS. If I create a file, I can no more rewrite
it. If I reboot, windows, access it, rewrite then later I can use it normally
via CIFS. So it is probably the attribute at file creation that are wrong.

-- eric
Comment 6 Eric Valette 2005-10-27 06:59:48 UTC
I checked against the latest version : the bug is still there and really annoys
me. Can we try to debug it?

NB : the /network/home is \\r-canaris\ceva6380

cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 1.39
Active VFS Requests: 0
Servers:
1) Name: 10.193.118.75  Domain: FTRD Mounts: 1 OS: Windows 5.0
        NOS: Windows 2000 LAN Manager   Capability: 0xd3fd
        SMB session status: 3   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
MIDs:

2) Name: 10.193.21.130  Domain: FTRD Mounts: 1 OS: Windows 5.0
        NOS: Windows 2000 LAN Manager   Capability: 0xd3fd
        SMB session status: 3   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
MIDs:

3) Name: 10.194.51.11  Domain: FTRD Mounts: 1 OS: Windows 5.0
        NOS: Windows 2000 LAN Manager   Capability: 0xd3fd
        SMB session status: 1   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
MIDs:

Shares:
1) \\p-europa\maps Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x4000f
PathComponentMax: 255 Status: 3 type: DISK      DISCONNECTED
2) \\PINGOUIN\inter-drd Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x4000f
PathComponentMax: 255 Status: 3 type: DISK      DISCONNECTED
3) \\r-canaris\ceva6380 Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x4000f
PathComponentMax: 255 Status: 1 type: DISK



NB : the /network/home is \\r-canaris\ceva6380


11 r-ptxp-ceva6380:/network/home->mkdir test2
12 r-ptxp-ceva6380:/network/home->cd test2
/network/home/test2
13 r-ptxp-ceva6380:/network/home/test2->cat > titi
A file
14 r-ptxp-ceva6380:/network/home/test2->cat >> titi
bash: titi: Permission denied
15 r-ptxp-ceva6380:/network/home/test2->
Comment 7 Steve French 2005-11-07 15:02:09 UTC
Trying to clean out old bugs and I puzzled how to recreate this.   See below:

smf-athlon64:/mnt/1 # cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 1.39
Active VFS Requests: 0
Servers:
1) Name: 192.168.0.5  Domain: WORKGROUP Mounts: 1 OS: Windows 5.1
        NOS: Windows 2000 LAN Manager   Capability: 0xe3fd
        SMB session status: 1   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
MIDs:

Shares:
1) \\192.168.0.5\msc Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x700ff
PathComponentMax: 255 Status: 1 type: DISK
smf-athlon64:/mnt/1 # cat > newfile
A file
smf-athlon64:/mnt/1 # cat >> newfile

Comment 8 Steve French 2005-11-07 15:05:16 UTC
so this seems to work on my try at recreating it.

If you know how to run ethereal or tcpdump could you save a network trace of
this problem (binary trace file - not ascii interpreted/formatted trace) and
attach it?

It would be even better if you made this two small trace files -
one of the
1) mount, followed by the "cat > file"
and the second a trace of the failing command
2) "cat >> file"

In addition turned on cifs debugging before the "cat > file"
Comment 9 Steve French 2005-11-07 15:07:27 UTC
sorry, last comment got truncated

dmesg output would also be useful after turning on tracing (immediately before
the  "cat > file" and turn it off immediately after the failing command)

echo 1 > /proc/fs/cifs/DebugData

then run the failing command(s)

then 

echo 0 > /proc/fs/cifs/DebugData

dmesg > logfile

and attach logfile
Comment 10 Eric Valette 2005-11-15 03:06:45 UTC
(In reply to comment #9)
> sorry, last comment got truncated
> 
> dmesg output would also be useful after turning on tracing (immediately before
> the  "cat > file" and turn it off immediately after the failing command)
> 
> echo 1 > /proc/fs/cifs/DebugData
> 
> then run the failing command(s)
> 
> then 
> 
> echo 0 > /proc/fs/cifs/DebugData
> 
> dmesg > logfile
> 
> and attach logfile


I did it and got nothing in dmesg except the boot trace. Shall I enable extra DEBUG things?

Also could you specify the tcpdum/etherreal command you would like me to run?
Comment 11 Eric Valette 2005-11-15 03:18:49 UTC
Created attachment 1572 [details]
failing command after a echo 1 > traceSMB
Comment 12 Eric Valette 2005-11-21 02:43:51 UTC
Tested with last version : No change 




mkdir test4
4 r-ptxp-ceva6380:/network/home->cd test4
/network/home/test4
5 r-ptxp-ceva6380:/network/home/test4->cat > toto
un petit contenu
6 r-ptxp-ceva6380:/network/home/test4->cat >> toto
bash: toto: Permission denied
7 r-ptxp-ceva6380:/network/home/test4->uname -a
Linux r-ptxp-ceva6380 2.6.15-rc2-git1 #1 PREEMPT Mon Nov 21 10:16:17 CET 2005 i686 GNU/Linux
8 r-ptxp-ceva6380:/network/home/test4->cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 1.39
Active VFS Requests: 0
Servers:
1) Name: 10.193.118.75  Domain: FTRD Mounts: 1 OS: Windows 5.0
        NOS: Windows 2000 LAN Manager   Capability: 0xd3fd
        SMB session status: 1   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
MIDs:

2) Name: 10.193.21.130  Domain: FTRD Mounts: 1 OS: Windows 5.0
        NOS: Windows 2000 LAN Manager   Capability: 0xd3fd
        SMB session status: 1   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
MIDs:

3) Name: 10.194.51.11  Domain: FTRD Mounts: 1 OS: Windows 5.0
        NOS: Windows 2000 LAN Manager   Capability: 0xd3fd
        SMB session status: 1   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
MIDs:

Shares:
1) \\p-europa\maps Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x4000f
PathComponentMax: 255 Status: 1 type: DISK
2) \\PINGOUIN\inter-drd Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x4000f
PathComponentMax: 255 Status: 1 type: DISK
3) \\r-canaris\ceva6380 Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x4000f
PathComponentMax: 255 Status: 1 type: DISK



Comment 13 Steve French 2005-11-21 08:01:15 UTC
Tried the same thing - still no luck reproducing it.  I suspect differences in our share permissions or Windows ACLs on the Windows server side are causing the problem.  See below:

smf-athlon64:~ # mkdir /mnt/test4
smf-athlon64:~ # cd /mnt/test4
smf-athlon64:/mnt/test4 # cat > toto
un petit contenu
smf-athlon64:/mnt/test4 # cat >> toto
smf-athlon64:/mnt/test4 # uname -a
Linux smf-athlon64 2.6.15-rc2-gd4735a0e #9 PREEMPT Sun Nov 20 16:05:45 CST 2005 x86_64 x86_64 x86_64 GNU/Linux
smf-athlon64:/mnt/test4 # cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 1.39
Active VFS Requests: 0
Servers:
1) Name: 192.168.0.5  Domain: WORKGROUP Mounts: 1 OS: Windows 5.1
        NOS: Windows 2000 LAN Manager   Capability: 0xe3fd
        SMB session status: 1   TCP status: 1
        Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0 In Send: 0 In MaxReq Wait: 0
MIDs:

Shares:
1) \\192.168.0.5\cifs Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x700ff
PathComponentMax: 255 Status: 1 type: DISK
Comment 14 Steve French 2005-11-21 08:15:12 UTC
There are various ways to capture more information, and a network trace would normally be the best place to start, but your trace SMB output did not seem to show any errors.   Two things I would like you to try:
1) check if the client permission check is causing the problem by disabling the client side of the permission (Linux mode bits) checks by adding the "noperm" mount option
2) run the second echo (the one that fails) via strace e.g.

       strace cat >> titi

which will display the system calls and their return codes so we can at least see if it is open or write which is failing.

I still would like to see dmesg output ("echo 1 > /proc/fs/cifs/DegugData" then run the "cat >> titi" get the failure and then "echo 0 > /proc/fs/cifs/DebugData" then "dmesg > cifs-debug-msg" and append the end of the cifs-debug-msg (which will contain the cifs trace, rather than bootup messages etc.) to the error report.
Comment 15 Eric Valette 2005-11-21 09:41:22 UTC
Do you use your athlon in 64 bits mode or in 32 bits mode.

FYI : I checked the Windows ACL on the server side : I'm in a mode where access rights are inherited from the parent directory, the parent directory being monted on Windows as H:. I haven't full control over the directory, just modifications. I changed the test directory permission (from modification to full control) without noticeable change.

I say again that once the file has been rewritten from windows, I can after that save it.
Comment 16 Eric Valette 2005-11-21 10:04:29 UTC
Created attachment 1582 [details]
small test program to do strace

As strace cat >> titi does not work because it takes the >> for strace, I wrote this small program.
Comment 17 Eric Valette 2005-11-21 10:06:56 UTC
Created attachment 1583 [details]
The EACESS error in strace

Note that if I do not pass O_WRONLY, It works.
Comment 18 Eric Valette 2005-11-21 10:07:42 UTC
Created attachment 1584 [details]
The dmesg after the echo 1 > ... DebugData
Comment 19 Eric Valette 2005-11-21 10:28:52 UTC
(In reply to comment #18)
> Created an attachment (id=1584) [edit]
> The dmesg after the echo 1 > ... DebugData
> 

And yes it does not contain any trace from cifs!!!
Comment 20 Eric Valette 2005-11-22 07:19:43 UTC
I tested as you suggested the noperm mount options : it makes the problem go away. What does it means? What else should I check? 
Comment 21 Steve French 2005-11-24 18:23:23 UTC
That it works with noperm checked means that it is a simple permission/owner issue - the default userid that you are using for the remote mount (in your case the mounter "root" since you did not specify one on mount)  and mask (022 deny write to group and others) means that you will be able to create a file (since that depends on the directory permissions that default to 0777) but not reopen and write such a file.

This will be a lot easier to deal with when the mapping of mode bits and owner to NT/CIFS ACLs is complete.

If you want to protect certain mounts then you could be mounting with a different default uid for each or if you want to allow other users to write files then the default umask could be changed.
Comment 22 Sebastian Voitzsch 2006-05-23 05:46:43 UTC
Created attachment 1914 [details]
ethereal captures

Hello,

I think I´m experiencing the same bug. I´m accessing one of those landrives which has FTP and SMB support based on RDC chipset. Using smbfs/smbclient everything is ok, access via cifs works as long as I don´t try to recreate a file. That means I´m able to append data to a created file (the cat > test.fil; cat >> test.fil works for me), but overwriting a file using cp fails:

harry ~ # cp /test /landisk
harry ~ # cp /test /landisk
cp: writing `/landisk/test': Input/output error

The server (there´s a minimal console) reports:

write file fail, read only!
SMB_Handle_WRITE(): write file error offset 0, ret -1004.
SMB_Handle_CLOSE(): close fid err 0x0

However, I can delete the file and copy it again. I´m logged in as root, the created file shows as -rw-r--r--. But I couldn´t get cifs to do any other permissions. The server doesn´t show the file permissions (only rudimentary console and dir cmd), but allows to set "ro" or "rw" mode. Setting to "rw" after creation didn´t change anything.

As "echo 1 > /proc/fs/cifs/DebugData" returned an error for me I captured a successful file creation and a failing rewrite with ethreal and attatched the file.

HTH,
Sebastian

------------8<---------------
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 1.42
Active VFS Requests: 0
Servers:
1) Name: 192.168.0.24  Domain:  Mounts: 1 OS:
        NOS:    Capability: 0x207
        SMB session status: 1   TCP status: 1
        Local Users To Server: 1 SecMode: 0x2 Req On Wire: 0 In Send: 0 In MaxReq Wait: 0
MIDs:

Shares:
1) \\landrive\public Uses: 1 Type:  DevInfo: 0x0 Attributes: 0x4006
PathComponentMax: 255 Status: 1 type: 0
Comment 23 Sebastian Voitzsch 2006-05-23 07:51:07 UTC
Well,

did some further investigation. I CAN append a created file using cat >> test.fil, and I CAN overwrite such a file using cat > test.fil. The only thing that fails for now is cp.

I noted cat uses OPEN_IF (3) disposition on appending and OVERWRITE_IF (5) on rewriting the file, while cp opens the file using OPEN (1). Doesn´t "open" include write access to an existing file?

I also discovered that "mv" works. Stracing cp and mv showed mv opens the file using O_WROLY|O_CREAT|O_LARGEFILE, while cp uses O_WRONLY|O_TRUNC|O_LARGEFILE. The mapping table says O_CREAT is mapped to FILE_OPEN_IF, which in terms of CIFS means OPEN_APPEND. So the server seems right in denying my request overwriting the whole file I think. Incorrect mapping? Or a "picky" server? Difficult to say as Win2k and WinXP don´t use NT-command set when talking to this server.

Sebastian
Comment 24 Sebastian Voitzsch 2006-05-23 10:00:16 UTC
Created attachment 1915 [details]
map O_TRUNC correctly to FILE_OVERWRITE (i.e., SMBOPEN_OTRUNC) instead of SMBOPEN_OAPPEND

Finally,

I found a solution for my cp mystery. It turns out that the O_TRUNC mode used by cp is not correctly mapped to cifs createmodes. According to file.c, line 240pp it should be mapped to FILE_OVERWRITE but was mapped to FILE_OPEN instead. The attatched patch corrects this. With the patch, cp works as expected for me.

Sebastian
Comment 25 Steve French 2006-05-24 11:50:30 UTC
The ethereal trace shows a clear server bug.  I have added the patch you suggest but it should not be necessary.

Your ethereal trace shows correct client behavior (O_TRUNC sets the filesize to zero then opens the file).

SetPathInfo of file size of "test" to zero (server returns success)
followed by
open (NTCreateX) of the file which returns file size of 0x24 (server returns success)
followed by write returning an unexpected error.

My guess is that the SetPathInfo is (incorrectly/dangerously) deferred by the server and causes the subsequent write to fail.
Comment 26 s2p 2007-07-05 06:14:25 UTC
I am experiencing this problem for nearly 2 years now, and while it has been only a slight annoyance until now, I'm preparing to switch nearly all of my company's it infrastructure (particularly the main data server running windows server 2003) and some of the production's stations to opensource, and now it becomes a serious hurdle for the final deployment. This problem affects several production software at various level from simply annoying (e.g. editing files with vim or openoffice) to virutally unusable (eclipse/subversion). Reading this bug report I tried too the noperm option without success, but I'm not sure of the usage : Can someone provide a working sample ?

s2p@sdatest.net
Comment 27 s2p 2007-07-06 03:31:16 UTC
It seems that cifs version 1.48a correct this problem (cf. http://groups.google.com/group/cfeclipse-users/browse_thread/thread/5aea36c834278c1c). Does anyone know when this new module release will be integrated on Ubuntu/Debian os ? Can anyone provide the steps to compile the 1.48a external module with Ubuntu Feisty (I tried without success) ?

Thanks,
Comment 28 Andrew Zabolotny 2008-12-10 08:34:25 UTC
This bug was tracked and solved here:

https://bugzilla.redhat.com/show_bug.cgi?id=221081

I think it can be closed now.
Comment 29 Steve French 2009-02-08 12:55:26 UTC
Now fixed and has been for a year or two.
Comment 30 Leo Smith 2009-03-25 15:30:38 UTC
I cannot say this has been fixed

At least not on current Debian releases.

I have installed a new debian Lenny desktop to replace a working WinPC and a MacosX setup, both of which were happily able to mount drives correctly from a samba server on an utterly reliable Debian etch system.

No matter what flags I use to mount with the current latest distro, the behaviour is the same.

I can create files, I can remove files but I cannot touch them nor can I change them.

So, touch test creates a file, but gives an error:

othello:/home/leo/tempest# mount 
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/sda9 on /home type ext3 (rw)
/dev/sda8 on /tmp type ext3 (rw)
/dev/sda5 on /usr type ext3 (rw)
/dev/sda6 on /var type ext3 (rw)
//tempest/leo on /home/leo/tempest type cifs (rw,mand)
othello:/home/leo/tempest# touch test
touch: setting times of `test': No such file or directory
othello:/home/leo/tempest# ls -l test
-rwx------ 1 leo leo 0 2009-03-25 20:10 test
othello:/home/leo/tempest# date
Wed Mar 25 20:23:36 GMT 2009
othello:/home/leo/tempest# echo hi > test
bash: test: No such file or directory
othello:/home/leo/tempest# ls -l test
-rwx------ 1 leo leo 0 2009-03-25 20:10 test
othello:/home/leo/tempest# rm test
othello:/home/leo/tempest# ls -l test
ls: cannot access test: No such file or directory
othello:/home/leo/tempest# echo "hi test" > test
othello:/home/leo/tempest# ls -l test
-rwx------ 1 leo leo 8 2009-03-25 20:24 test
othello:/home/leo/tempest# 

Debian reports the current stable pacakge as 

Package: smbfs (2:3.2.5-4)

If you can confirm that the bug was not fixed in this version, I will take it up with the debian maintainers. Otherwise I think it should be reopened