Thanks Gordon. thats what I did already. It didn't worked with a normal domain account or the domain administration account. With both accounts I could connect to the samba box and copy files without any problem.
I solved the problem now somehow, but haven't a clue why. At some point I skipped trying to map the directory as a drive on the windows server. I used UNC-Pathes instead to copy the files. I used xxcopy to sync files between the windows server and the samba box. The samba box directory was filled with files from a previous sync process. In the first attempt to overwrite these files it didn't worked. As soon as I moved the files and folders to another temporary directory and restartet the sync process everything just worked fine. So the problem was overwriting old files. In the first moment I thought it was due to a permission problem. But I compared the old files with the new synced ones with getfacl and found no difference. I don't see what went wrong, but I can assume that it has something to do that we moved our system from a SuSE Linux Samba installation to a Debian Sarge Samba installation. All files are mounted from a NAS storage.
Has somebody an idea what could cause that behaviour?
W2k by default runs scheduled tasks as "system" user, which isnt a samba user. somewhere in the config of the W2K job schedule interface (it may be under an "advanced" button) you can change the user that the job runs under. Change it to a user who is in your samba system, and can read/write the share you want to access.
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
