Created attachment 2562 [details]
smb.conf for samba domain member

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

Move to CIFS fs product

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()? 

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. 

 

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 2.6.25.10-86.fc9.i686, 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,
  Trans2=QUERY_FILE_INFO:basic, Trans2=SET_FILE_INFO, Trans2=SET_FILE_INFO,
  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.

Can you please verify on the latest kernel if possible?
I verified on 2.6.27.8 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

I checked my current setup:
Fedora 9, kernel 2.6.27.7-53.fc9.i686
windows server: Windows Server 2003 5.2
linux server: samba-3.2.7-0.23.fc9

Results:
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.

I repeated the tests with 
kernel 2.6.27.12-78.2.8.fc9
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

Christian,

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

(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.

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

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.

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.

#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]);
        close(fd0);
}

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 //127.0.0.1/<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?

Found this....

http://www.faqs.org/docs/samba/ch05.html

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

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 //127.0.0.1/smb8 /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

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

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.

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.

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
succeeds

[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
fails.

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


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
fails.

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


So even smbclient fails just like cifs vfs client.  
I think this is not a cifs bug but more of a samba server issue.

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,

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
Versions:
Fedora 11
samba-3.3.2-0.33.fc11.x86_64
kernel-2.6.29.6-217.2.16.fc11.x86_64

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.

Not an issue with Samba Version 3.4.0-GIT-26e114b-devel

also tested against windows 2003 and cp -p works with cifs.ko