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.
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
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
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.
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.
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
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->
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
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"
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
(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?
Created attachment 1572 [details] failing command after a echo 1 > traceSMB
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
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
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.
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.
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.
Created attachment 1583 [details] The EACESS error in strace Note that if I do not pass O_WRONLY, It works.
Created attachment 1584 [details] The dmesg after the echo 1 > ... DebugData
(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!!!
I tested as you suggested the noperm mount options : it makes the problem go away. What does it means? What else should I check?
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.
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
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
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
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.
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
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,
This bug was tracked and solved here: https://bugzilla.redhat.com/show_bug.cgi?id=221081 I think it can be closed now.
Now fixed and has been for a year or two.
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