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.
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 220.127.116.11-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 18.104.22.168 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
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 22.214.171.124-53.fc9.i686
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.
I repeated the tests with
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
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
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?
(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
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.
main(int arc, char **argv)
int fd0; // file descriptors
int flags; // open flags
int rc; // return code
flags = O_RDWR;
fd0 = open(argv, flags);
printf("result: %d open of file %s with flags 0x%x\n", fd0, argv, flags);
rc = fchown(fd0, 0, 0);
printf("rc: %d fchown of file %s\n", rc, argv);
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?
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
# 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
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
I tried it again with
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.
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
[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.
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
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