Bug 4578 - date attributes are not preserved copying via cifs mounted share
date attributes are not preserved copying via cifs mounted share
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
x86 Linux
: P3 normal
: ---
Assigned To: Steve French
Depends on:
  Show dependency treegraph
Reported: 2007-04-29 10:40 UTC by Dave Brain
Modified: 2009-10-27 14:30 UTC (History)
5 users (show)

See Also:

smb.conf for samba domain member (4.52 KB, application/octet-stream)
2007-04-29 10:47 UTC, Dave Brain
no flags Details
fstab for samba domain member (1.51 KB, application/octet-stream)
2007-04-29 10:51 UTC, Dave Brain
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Brain 2007-04-29 10:40:58 UTC
Hi Samba team.

I've been having a torrid time copying files from a gentoo samba system to a windows 2003 server and to windows xp systems.

using combinations of cp -p , cp -a , cp --preserve=all , all the copied files inherit the current system time. However, if a null file is copied, then the date attributes are preserved! 

The windows share is mounted uising the cifs kernel module. I've tried this with kernel 2.6.17, 2.6.18, 2.6.19, and 2.6.20. The behaviour is the same.

I've tried to help the gentoo bug wranglers by installing virtual machines to eliminate recent MS patches etc. This did not really help me, apart from installing a debian 3.1 VM. From that system the dates are preserved. This leads me to believe that there maybe an issue with the coreutils package. To further verify this, I installed a debian etch 4.0 vm and this behaves exactly as my gentoo box, further leading me to believe there is an issue with the way cp is using utimes and mtimes. 

What I would really like is for someone to verify this as I find it hard to beleive I am the only user having major problems preserving file date and time attributes copying files.
Comment 1 Dave Brain 2007-04-29 10:47:24 UTC
Created attachment 2562 [details]
smb.conf for samba domain member
Comment 2 Dave Brain 2007-04-29 10:51:04 UTC
Created attachment 2563 [details]
fstab for samba domain member 

this is the fstab from the samba domain member showing how the cifs share is mounted
Comment 3 Gerald (Jerry) Carter 2007-04-29 17:07:19 UTC
Move to CIFS fs product
Comment 4 Dave Brain 2007-04-30 04:54:19 UTC
I've downgraded this bug to normal, as I have found a workaround that allows me to copy data and preserve the date stamps.

using scp allows me to preserve with scp -p

I don't know if this helps to narrow down where this bug is taking place, as it may suggest that its not a cifs issue but something to do with the way cp uses utimes()/mtimes()? 
Comment 5 Eddy Lehrer 2008-03-24 13:18:10 UTC
I ran into the same problem when copying files using rsync -t.  However, when using the copy function of mc the dates are preserved.  If I specific smbfs instead of cifs for the mounted share in fstab, then rsync -t (and also cp -a ) will preserve the dates. 

I am using kernel 2.6.13-15 and have tried rsync 2.6.6 and 3.0.  

This bug causes rsync to needlessly copy files. 

Comment 6 Christian Lupien 2008-07-29 17:47:07 UTC
I have the same problem.

cp -p or cp --preserve=timestamps looses the timestamps and the modification time is set to the current time.

But using touch -d "1/1/2008" /to/smb/file does change the modification time and using rsync -a also gets the timestamps working fine.

I have tested this from a linux machine (fedora 9, samba-3.2.0-2.17.fc9.i386, kernel, cifs 1.52) to my smb server on the same machine and to a windows Server 2003 SP2. (But the problem as been around for a long time, I think I remember Fedora 5 having the same problem).

The same problem shows up whether the mount is with the kernel cifs or if I use a fuse filesystem such as usmb. So this does not only affect cifs but also libsmbclient.

I explored the problem some more by capturing the network traffic and the commands sent for cp -p and for touch -d are almost identical except for the written data in cp -p.

From wireshark captures
cp -p: Open AndX, Write AndX, Trans2=SET_PATH_INFO, Trans2=QUERY_PATH_INFO,
       Set Information, Trans2=Query_PATH_INFO, Close

touch: Open AndX, Trans2=SET_PATH_INFO,Trans2=QUERY_PATH_INFO, Close

Note that the responses to Query_PATH_INFO in cp -p show the correctly updated timestamp but once the Close request is processed the file timestamps jumps to the current date.

I captured a log from a win XP copy operation and it goes something like:
 NT Create AndX, Trans2=QUERY_FILE_INFO:internal, Trans2=QUERY_FILE_INFO:basic,
  Write AndX, Trans2=SET_FILE_INFO, Close
And here the timestamps gets conserved.

So the write seem to postpone a timestamps update until the close statement 

There are workaround on the command lines but that some commands (cp -p) don't work as expected (like touch or rsync) is strange and for a GUI like nautilus there is no workaround to keep the timestamps in sync.

Is anybody looking at solving this?
I can do more tests but I don't have the time to dig much more in the smb/cifs protocol especially since the timestamp stuff looks quite complicated.

Comment 7 shirishpargaonkar@gmail.com 2009-02-03 17:56:56 UTC
Can you please verify on the latest kernel if possible?
I verified on and seems to be working i.e. date and time are
preserved during copy. For example,

# ls -l autoinst.xml
-rw-r--r-- 1 root root 39795 Jan 26 21:45 autoinst.xml

# date
Sun Feb  1 19:49:23 CST 2009

# cp autoinst.xml /mnt/smb_a
# ls -l /mnt/smb_a/autoinst.xml
-rwxrwSrwx 1 root root 39795 Feb  1 19:47 /mnt/smb_a/autoinst.xml

# cp -pa autoinst.xml /mnt/smb_a/ai.xml
# ls -l /mnt/smb_a/ai.xml
-rwxrwSrwx 1 root root 39795 Jan 26 21:45 /mnt/smb_a/ai.xml
Comment 8 Christian Lupien 2009-02-03 19:29:03 UTC
I checked my current setup:
Fedora 9, kernel
windows server: Windows Server 2003 5.2
linux server: samba-3.2.7-0.23.fc9

with the windows server it works as long as I do the test as root.
If I do the tests as a regular user, I create the files but the date is not set and I cannot change it with the touch commands. If I mount using the cifs noperm option then it works for both root and the user.
The error message is: Operation not permitted

with the linux server it is the same as before. cp -p does not preserve the date but touch can fix it.
Comment 9 Christian Lupien 2009-02-06 18:54:03 UTC
I repeated the tests with 
smaba 3.2.8-0.25.fc9

I get the same results. BTW the error message when using a linux server is
cp: preserving permissions for `/mnt/test/test.pdf': Permission denied
Comment 10 Guenter Kukkukk 2009-02-09 18:30:41 UTC

as you posted:
  "I get the same results. BTW the error message when using a linux server is
   cp: preserving permissions for `/mnt/test/test.pdf': Permission denied"

This one looks different than the time stamp issues, here permissions come
into play.

What underlying file system do you use on this failing samba share?
I got a similar problem when XFS was used, which is more strict/picky
when "default ACLs" are tried to be applied to a file - was a samba bug,
which has been fixed some days ago.

Does the cp -p ... permissions error still show, when the cifs mount option "noacl" is used?
Cheers, Günter
Comment 11 shirishpargaonkar@gmail.com 2009-02-09 22:12:31 UTC
(In reply to comment #10)

Yes, it is not a timestamp issue but a changing ownership issue

fchown(4, 0, 0)                         = -1 EACCES (Permission denied) 

So we try to set the ownership of the destination file to that of the 
source file (in this case uid and gid both are 0, root,root) which is
what fails.

noacl did not make a difference.
Comment 12 shirishpargaonkar@gmail.com 2009-02-09 22:42:18 UTC
This is the corrosponding error in samba server log (log level 10)

[2009/02/09 22:32:06,  5] smbd/filename.c:unix_convert(290)
  conversion finished file4 -> file4
[2009/02/09 22:32:06,  3] smbd/trans2.c:call_trans2setfilepathinfo(6702)
  call_trans2setfilepathinfo(6) file4 (fnum -1) info_level=512 totdata=100
[2009/02/09 22:32:06, 10] smbd/trans2.c:smb_set_file_unix_basic(5955)
  smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC: name = file4 size = 0, uid = 0, gid = 0, raw perms = 037777777777
[2009/02/09 22:32:06, 10] smbd/trans2.c:smb_set_file_unix_basic(6015)
  smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC changing owner 0 for path file4
[2009/02/09 22:32:06,  3] smbd/error.c:error_packet_set(61)
  error packet at smbd/trans2.c(6958) cmd=50 (SMBtrans2) NT_STATUS_ACCESS_DENIED
Comment 13 shirishpargaonkar@gmail.com 2009-02-09 22:50:41 UTC
When we do not copy with preserve (-p) option, the user,group at the
destination file is nobody,nobody, to start with it is nobody,nobody, cp -p
tries to set it to source owner,group (root,root in this case) which is
when the error occurs.
Comment 14 Christian Lupien 2009-02-10 17:14:30 UTC
I agree with the comments above. What happens with the windows server is a problem with permissions.

noacl had no effect. But using the setuids option did help. With that option cp -p as a regular user (mount as root) worked fine as long as the file did not already exist (and owned by root). 

So I would say with the windows server it works as expected but I still have the problem when using a linux samba server. Can anybody reproduce that?

My linux filesystem is ext3.
Comment 15 shirishpargaonkar@gmail.com 2009-02-19 09:42:50 UTC
#include <stdio.h>
#include <fcntl.h>

main(int arc, char **argv)
        int fd0;        // file descriptors
        int flags;      // open flags
        int rc;         // return code

        flags = O_RDWR;
        fd0 = open(argv[1], flags);
        printf("result: %d open of file %s with flags 0x%x\n", fd0, argv[1], flags);
        rc = fchown(fd0, 0, 0);
        printf("rc: %d fchown of file %s\n", rc, argv[1]);

In this simple program, fchown succeeds over local filesyetem if I am logged in 
as root but fails if I have networked logged on as user root over the very same 
local filesystem exported as a samba share on the same machine over the 
loopback interface i.e.
 mount -t cifs //<samba_share> <mount_point> -o user=root,pass=<root_password>

If I change to fchown(fd0, 0, -1); and fchown(fd0, -1, 0);, they succeed on
the local filesystem.

I can't figure out why SMB_VFS_CHOWN faiuls when called in function 
smb_set_file_unix_basic in file trans2.c fails.

I think samba needs to look at this.  Can we change the ownership of this bug 
to the samba server component instead of smb/cifs client?
Comment 16 shirishpargaonkar@gmail.com 2009-03-10 13:36:58 UTC
Found this....


For the most part, the files and directories contained in the mounted smbfs 
filesystem will work just like any others, except for limitations imposed by 
the nature of SMB networking. For example, not even the superuser can perform 
the operation:

# chown root lectures
chown: changing ownership of 'lectures': Operation not permitted

because SMB shares do not intrinsically support the idea of ownership. Some 
odd behaviors can result from this. For example, the command:

# chmod 777 readme.txt

does not produce an error message, although nothing has been changed. 
The file readme.txt still has permissions set to 664:

# ls -l readme.txt
-rw-rw-r--    1 jay      jay           131 Jan 15 05:01 readme.txt

Aside from little things such as these, the mounted smbfs filesystem can be 
used in conjunction with virtually any application, and you might be 
pleasantly surprised at how nicely it integrates with your Linux-based 
computing environment
Comment 17 shirishpargaonkar@gmail.com 2009-03-10 14:08:36 UTC
Can't change ownership of a file in a samba share locally mounted over loopback

cifstest8:/tmp/cifstest8 # ls -l file2
-rwxrwxrwx 1 root root 0 Mar 10 10:47 file2

cifstest8:/tmp/cifstest8 # mount -t cifs // /mnt/smb_a -o user=root,pass=password

cifstest8:/tmp/cifstest8 # chown nobody.nobody /mnt/smb_a/file2
chown: changing ownership of `/mnt/smb_a/file2': Permission denied

Comment 18 shirishpargaonkar@gmail.com 2009-03-10 14:20:28 UTC
The chown command fails when used within smbclient also

cifstest6:~ # smbclient //cifstest8/smb8 -U root
Enter root's password:
Domain=[CIFSTEST8] OS=[Unix] Server=[Samba 3.4.0-GIT-e6a5f11-devel]
smb: \> chown 65534 65534 file2
NT_STATUS_ACCESS_DENIED chown file \file2 uid=65534, gid=65534
Comment 19 shirishpargaonkar@gmail.com 2009-03-11 09:54:07 UTC
cp -p or cp -a works correctly with samba server
 smbd -V
 Version 3.0.22-3-SUSE-CODE10

I tried it again with
 smbd -V
 Version 3.2.5-1.3-2022-SUSE-CODE11
and it fails.

So this is not a cifs vfs client bug but a samba server bug.
Comment 20 shirishpargaonkar@gmail.com 2009-03-12 14:55:58 UTC
I tested on samba server on RHEL 5.3 and no such problem during cp -p.

smbd -V
Version 3.0.33-3.7.el5

So this problem looks exists specifically on samba server on SuSE/SLES

Definitely not a cifs vfs client bug.
Comment 21 shirishpargaonkar@gmail.com 2009-03-26 21:40:57 UTC
This is from a smbd strace,

On a  smbd -V Version 3.0.33-3.7.el5, using this operation within smbclinet
 smb: \> chown 65534 65534 cft6.touch.umask_0012_createmask_400

[pid 20665] chown("cft6.touch.umask_0012_createmask_400", -1, 65534) = 0

On a smbd -V Version 3.4.0-GIT-e6a5f11-devel, using the same operation, 
 smb: \> chown 65534 65534 file2
         NT_STATUS_ACCESS_DENIED chown file \file2 uid=65534, gid=65534

[pid  8730] chown("file2", 65534, 4294967295) = -1 EPERM (Operation not 

And on a smbd -V Version 3.2.5-1.3-2022-SUSE-CODE11, using the same operation,
 smb: \> chown 65534 65534 file1
         Pushing string of 'unlimited' length into non-SMB buffer!
         NT_STATUS_ACCESS_DENIED chown file \file1 uid=65534, gid=65534

[pid  6843] chown("file1", 65534, 4294967295) = -1 EPERM (Operation not 

So even smbclient fails just like cifs vfs client.  
I think this is not a cifs bug but more of a samba server issue.
Comment 22 Dave Brain 2009-04-05 07:41:32 UTC
This 'bug' does not exist on all distro's and has to be down to a common cause.

from testing, it does not appear to be a kernel issue as distro's that display this behaviour such as gentoo, ubuntu 8.10, debian 5 with a common kernel from kernel.org the problem shows under 2.6.26 through 2.6.29.

The distro's that do not behave like this so far are ununtu 8.04, debian 4 I note other posters say some SuSE and Fedora products work,
Comment 23 Christian Lupien 2009-09-03 13:16:45 UTC
This is an update on the time problem.
The problem is still there when trying to copy with time preservation from
linux to a samba server
Fedora 11
Comment 24 Christian Lupien 2009-09-03 13:25:25 UTC
I also want to reiterate that libsmbclient also seems to have the same problem and it is still there (as seen trough fusesmb and gnome .gvfs). With that it does not even work on windows server.
But at least gnome (2.26.3) nautilus seem to be using a work around because it works correctly in the GUI.
Comment 25 shirishpargaonkar@gmail.com 2009-10-13 05:07:23 UTC
Not an issue with Samba Version 3.4.0-GIT-26e114b-devel
Comment 26 Steve French 2009-10-27 14:30:55 UTC
also tested against windows 2003 and cp -p works with cifs.ko