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
