Multiple cifs issues - CIFS: reset ATTR_READONLY on Windows

[disabled.user]

Binary package hint: smbfs

Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.

I have multiple shares mounted via fstab, looking like this (w/o the newlines):

//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,
dir_mode=0755,file_mode=0644,iocharset=iso8859-15

Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed, and "umount -a" won't work as supposed.

But my main grievance is the following:

Once a file gets its mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.

Also, when viewing a PDF-file on such a cifs-mounted share, KPDF constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.

smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.

For now, I have no further clue what may be causing this behaviour.

EDIT:
tar also confirms the "unstableness" of files on cifs-shares when creating a tar-archive. Output from tar (slightly modified):

tar: /mnt/[path]/[filename]: file changed as we read it

[Gilles (ubuntugc1)]

I must admit myself I can add some further "weight" on this "unstableness" issue.

I have been trying to do various tests using cifs and a NAS drive and I got a lot of funny results. For example when copying data, small files will go through fine but bigger ones will get an "access denied" exception (and yes there was enough space on the NAS drive!)

For more details see #74427 (I am not sure at this stage if this is exactly the same problem, hence a different bug report. But in any case the feeling of "unstableness" is the same!).

[Urs Fleisch (ufleisch)]

I can confirm this bug.

My system configuration is:
Ubuntu Linux Dapper (kernel package linux-image-2.6.15-23-386_2.6.15-23.39_i386.deb) client accessing Windows Server 2003 3790 Service Pack 1 (no UNIX extensions).

Problem description:
When all write permission bits are removed from a file on the Windows share (e.g. using chmod ugo-w filename), the read-only bit is set in the file (as seen in the Windows Explorer). Now it is not possible to get the write permissions back (e.g. using chmod ugo+w filename). The read-only bit has to be removed in the Windows Explorer. When this is done, the file is still displayed to be read-only (ls -l filename), but it can be made writeable (chmod ugo+w filename).

When the following patch is applied (discovered by Alan Tyson of HP, reported by Jeff Layton), the writeable bits are displayed correctly as soon as the read-only bit is removed in the Windows Explorer. The main problem, however, still exists as it is not possible to make the file writeable from the Linux CIFS client.

see:
http://lists.samba.org/archive/linux-cifs-client/2007-January/001668.html
http://lists.samba.org/archive/linux-cifs-client/2007-March/001808.html
http://lists.samba.org/archive/linux-cifs-client/2007-March/001827.html

--BEGIN OF PATCH----------------------------------------------------------------
--- linux-source-2.6.15-2.6.15.orig/fs/cifs/inode.c 2006-03-02 22:18:38.000000000 +0100
+++ linux-source-2.6.15-2.6.15/fs/cifs/inode.c 2007-03-15 16:37:45.000000000 +0100
@@ -475,6 +475,12 @@
       mode e.g. 555 */
    if (cifsInfo->cifsAttrs & ATTR_READONLY)
     inode->i_mode &= ~(S_IWUGO);
+ else if ((inode->i_mode & S_IWUGO) == 0)
+ /* the ATTR_READONLY flag may have been */
+ /* changed on server -- set any w bits */
+ /* allowed by mnt_file_mode */
+ inode->i_mode |= (S_IWUGO &
+ cifs_sb->mnt_file_mode);
   /* BB add code here -
      validate if device or weird share or device type? */
   }
--- linux-source-2.6.15-2.6.15.orig/fs/cifs/readdir.c 2006-03-02 22:18:38.000000000 +0100
+++ linux-source-2.6.15-2.6.15/fs/cifs/readdir.c 2007-03-15 16:39:05.000000000 +0100
@@ -178,6 +178,10 @@
   tmp_inode->i_mode |= S_IFREG;
   if (attr & ATTR_READONLY)
    tmp_inode->i_mode &= ~(S_IWUGO);
+ else if ((tmp_inode->i_mode & S_IWUGO) == 0)
+ /* the ATTR_READONLY flag may have been changed on */
+ /* server -- set any w bits allowed by mnt_file_mode */
+ tmp_inode->i_mode |= (S_IWUGO & cifs_sb->mnt_file_mode);
  } /* could add code here - to validate if device or weird share type? */

  /* can not fill in nlink here as in qpathinfo version and Unx search */
--END OF PATCH------------------------------------------------------------------

Investigating the problem further, I found out that the problem occurs only if no other attribute is set on the file. If I set the archived or hidden bit in the Windows Explorer or unmark the "for fast searching, allow Indexing Service to index this file" checkbox (which sets the ATTR_NOT_CONTENT_INDEXED bit), the read-only bit can be cleared from the Linux client. Looking into the function cifs_setattr() in fs/cifs/inode.c and adding some debug output, it can be seen t...

[Mathias Gug (mathiaz)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Can you specify which version of the kernel you're using ?

[Urs Fleisch (ufleisch)]

As mentioned above, the kernel is linux-image-2.6.15-23-386_2.6.15-23.39_i386.deb, but the same problems exist also for the current feisty kernel (2.6.20-16-generic).

I sent my patch to the linux-cifs-client mailing list

http://lists.samba.org/archive/linux-cifs-client/2007-March/001843.html
http://lists.samba.org/archive/linux-cifs-client/2007-March/001851.html
http://lists.samba.org/archive/linux-cifs-client/2007-March/001876.html
http://master.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=066fcb06d3e27c258bc229bb688ced2b16daa6c2
http://lists.samba.org/archive/linux-cifs-client/2007-April/001900.html
http://master.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=5268df2ead6def933ace27ab4d46f67d2989b905

The patches were put into the main kernel tree and are part of the official kernel since version 2.6.22, so the problems should be solved in gutsy.

[Launchpad Janitor (janitor)]

[Expired for samba (Ubuntu) because there has been no activity for 60 days.]

[Mathias Gug (mathiaz)]

Reopening.

[Chuck Short (zulcss)]

Re-assigning to correct package. Since its a kernel fix.

[Saivann Carignan (oxmosys)]

This bug describe more than one issue. In order to help developers, it's always a good idea to separate bugs to make sure that they get all fixed. Linux ubuntu Gutsy is now released. Can you confirm if this bug is now fixed for you?

[Leann Ogasawara (leannogasawara)]

I'm marking this 'Fix Released' against Gutsy as the patches mentioned by Urs in https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/62607/comments/4 appear to be in the Gutsy kernel source. If this isn't the case, please test against the actively developed Hardy Heron kernel and report back your results: http://www.ubuntu.com/testing . Thanks.