none
problems with SyncToy 2.1, a samba-server and read only files RRS feed

  • Question

  • Hi!

    I think there is a problem with SyncToy 2.1 while synchronising read only files to a samba server (on a NAS). You will always get the error message:
    HRESULT: 0x80070005 (E_ACCESSDENIED)

    It seems to me that first the read only flag is set. Afterwards SyncToy tries to copy the file content, but the samba server does not allow it.

    Does anybody has the same problem?

    bellheim

    Sunday, December 20, 2009 12:03 AM

Answers

  • Hi Bellheim,

    With some experiments, this seems to be something related with the samba share you are using ( I assuemd this by reading the syncToy log file provided above), I can even repro this simply by renaming a READONLY files when epening the share with explorer.exe on the Windows machine.

    I just tried using NFS shares to do this and it can be used as a workaround. here is what I did:

    Assume you have the file struction like this /home/test/ on the Linux and /home is the NAS drive and test is the target folder.

    1. on the linux box, ensure the nfs service is running, and configure and export /home

    2. on the windows machine, mount the exported linux drive, say :

        Mount \\<linux IP>\home *
              T: is now successfully connected to \\<linux IP>\home
    3. configure the syncToy, set the right folder as T:\home\test

    this worked fine based on my experience, would you try this out to see if this worked with you under your envrioment ?

    Thanks
    Yunwen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, January 9, 2010 2:40 AM
    Moderator

All replies

  • Hi bellheim,

    What is the system of your NAS? I am not familiar with Samba but maybe I can give you some information.

    SyncToy detects and copies file changes with the help of Windows IO functions. So if Samba works well with these IO functions, it should work well with SyncToy, too.

    Your issue may be caused by the settings, especially permission settings, of the NAS server. Would you like to check if SyncToy can work with writable files in your scenario, please? And what would happen if you copy a read-only file to the Samba server by other applications such as Windows explorer or xcopy? Are all read-only files suffering this problem or only some of them have this issue?

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, December 22, 2009 9:09 AM
  • Hi JiGuang!

    Thank you for your answer!

    I use the Netgear ReadyNAS Duo RND2110.

    SyncToy works normal with all other files except the read only files.

    It is possible to copy read only files with the windows explorer to the same NAS share-folder. I tried it with the same read only files from the SyncToy left-folder.
    Afterwards it is not possible to delete the read only files directly. First I have to remove the read only flag.

    The problem exist with all read only files.

    A colleague uses a Buffalo TeraStation and has the same problem with readonly files.

    bellheim
    Tuesday, December 22, 2009 7:44 PM
  • Hi bellheim,

    Afterwards it is not possible to delete the read only files directly. First I have to remove the read only flag.” This could be the key to explain your issue.

    SyncToy tries to delete the file and stored a backup in Windows “Recycle Bin” before overwriting the content of any file, so that the users have a place to find the lost information if necessary. It seems that your Samba settings did not allow SyncToy to perform the deleting action.

    So would you mind trying if the following steps can work around your issue, please: 
     1. Select the folder pairs in question in SyncToy.
     2. Click the “Change options…” button (which is placed in SyncToy main panel and looks like a link).
     3. Uncheck the box of “Save overwritten files in the Recycle Bin” in the popped up dialogue window.
     4. Click “OK” to apply your change and close the dialogue box.
     5. If the steps above do not work, please try setting the “delete readonly” option of the folder in your Samba to “yes”.

    Sorry for the inconvenience. Please let us know your result. Any information is helping us to improve SyncToy.

    Thanks very much


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, December 23, 2009 6:04 AM
  • Hi JiGuang!

    I removed already the flag "Save overwrite files in the recycle bin". It did not work too.

    The problem occurs already at the first start of this folder pair. So the read only files are never copied to the right folder. So maybe SyncToy creates first the file with the attributes and afterwards it copies the content. And at this time the file is already read only.

    I'm not at home at the moment, so I will check Point 5.) in a few days.

    Thank you again for your answer!

    bellheim
    Friday, December 25, 2009 8:46 AM
  • I see. I’ll wait for your news. And would you mind to share the call stack information about the exception in question from SyncToy log file, please? I want to try to some debug work while waiting.

    I am very sorry that I have not located your issue yet. For now, we do not the necessary environment to set up a Samba server here. So your information is very important for us to know how to fix this issue. Your work will also help a lot of people who are suffering the same problem. (I saw people talk about this SyncToy exception in NAS forums)

    We appreciate your help! Hope we can work out the problem together.

    Thanks, and happy holidays!


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, December 25, 2009 10:07 AM
  • Hi JiGuang!

    I had some minutes at home today between the christmas-family-meetings ;-)

    Regarding Point 5):
    I removed the readonly-flag from the right-folder on the NAS, but the same result (I used the Windows-Explorer to remove the readonly-flag).

    I created a test folder pair in SyncToy with 2 files on the left folder (writablefile.txt and readonlyfile.txt). You find the content of the log file (File --> View Log) at the end of this posting.

    Thank you very much and happy holidays too!
    bellheim

    -----

    SYNC: 12/25/2009 13:35:31:373: Started scanning directory : C:\synctoytest\
    SYNC: 12/25/2009 13:35:31:382: Started scanning directory : \\RNASDUO\backup\synctoytest\
    SYNC: 12/25/2009 13:35:31:557: Stopped scanning directory : C:\synctoytest\
    SYNC: 12/25/2009 13:35:31:598: Stopped scanning directory : \\RNASDUO\backup\synctoytest\
    SYNC: 12/25/2009 13:35:31:715: Preview of SyncToy Test (C:\synctoytest\, \\RNASDUO\backup\synctoytest\) in time 00:00:00:343.
    SyncToy action was 'Echo'
    Found 1 actions to perform.
    Found 2 files that did not require action.
    Analyzed 5,8 files per second.

    SYNC: 12/25/2009 13:35:32:131: SyncToy run of SyncToy Test (C:\synctoytest\, \\RNASDUO\backup\synctoytest\) completed at 25.12.2009 13:35:32.
    SyncToy action was 'Echo'.
    SyncToy options were:
     Active for run all
     All files included
     No files excluded
     Do not check file contents
     Include read-only files
     Include hidden files
     Include system files
     Do not backup older files
     All subfolders included
    SyncToy run took 00:00:00:320.
    Copied 0 bytes in 1 files in 00:00:00:320.
    Bytes per second 0,0, files per second 3,1.
    Warning: 1 failures occured.
    You can retry by selecting "Run" again or select "Preview" to see
    the operations that remain to be performed.

    SYNC: 12/25/2009 13:35:32:131: *** Error: Cannot write to the destination file. Zugriff verweigert (Ausnahme von HRESULT: 0x80070005 (E_ACCESSDENIED)) Copying C:\synctoytest\readonlyfile.txt to \\RNASDUO\backup\synctoytest\readonlyfile.txt

    -----

    Friday, December 25, 2009 12:38 PM
  • Hi bellheim,

    Thanks for your information. But I think that you had some misunderstanding about my “Point 5” (Excuse me that I did not express clearly):
    The “delete readonly” option, is a Samba server option that indicates whether read only files are protected from being deleted in certain Samba server folders. The option is set as “NO” by default, which does not allow you to delete any read only files. So my “Point 5” is wishing you could try to set this option to “YES”. (And you do not need to change the “read-only” flag of any file or any folder.)

    I am debugging into SyncToy to verify my idea, have got no progress yet. I wish you could try Point 5 again and have a better luck. :)

    Thanks very much


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, December 28, 2009 11:12 AM
  • Hi bellheim,

    Thanks for your information. But I think that you had some misunderstanding about my “Point 5” (Excuse me that I did not express clearly):
    The “delete readonly ” option, is a Samba server option that indicates whether read only files are protected from being deleted in certain Samba server folders. The option is set as “NO” by default, which does not allow you to delete any read only files. So my “Point 5” is wishing you could try to set this option to “YES”. (And you do not need to change the “read-only” flag of any file or any folder.)

    I am debugging into SyncToy to verify my idea, have got no progress yet. I wish you could try Point 5 again and have a better luck. :)

    Thanks very much


    This posting is provided "AS IS" with no warranties, and confers no rights.

    I am running into the same issue.

    The 'delete readonly' Samba config option does not fix the issue.

    The only way I was able to get it to work was remove the read-only attribute on the Windows side or add the 'force create mode = 700' option to my smb.conf (Samba config).

    It appears the problem is on the SyncToy side with read-only files. The file ends up on the Linux side without any owner write permissions and SyncToy must not be able to copy the file over. The second fix I mention above forces every file copied over Samba to include an owner write permission. SyncToy then works when the owner write persmission is set.

    JiGuang, I have no idea how this is implemented in SyncToy but it sounds like when read-only files are copied they should be completely transferred before the write permission is removed.
    • Proposed as answer by JiGuang Tuesday, January 5, 2010 10:36 AM
    Saturday, January 2, 2010 1:00 AM
  • Thank you very much, AcesOver.

    Your information is very helpful. We would try checking the SyncToy create file process to see if there is something we can do on this issue.

    About your 'force create mode = 700' approach, thanks again! This seems an appropriate work around for current SyncToy. I hope this work around is acceptable in yours and bellheim’s scenarios.

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, January 5, 2010 10:36 AM
  • Thank you very much, AcesOver.

    Your information is very helpful. We would try checking the SyncToy create file process to see if there is something we can do on this issue.

    About your 'force create mode = 700' approach, thanks again! This seems an appropriate work around for current SyncToy. I hope this work around is acceptable in yours and bellheim’s scenarios.

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Well it isn't really meant to be a work around. It is a complete hack because it messes with the file permissions via Samba.

    It is a very temporary bandaid.

    The bug needs to be fixed on the SyncToy side in the way it deals with creating read-only files.
    Wednesday, January 6, 2010 7:21 PM
  • Thank you very much, AcesOver.

    Your information is very helpful. We would try checking the SyncToy create file process to see if there is something we can do on this issue.

    About your 'force create mode = 700' approach, thanks again! This seems an appropriate work around for current SyncToy. I hope this work around is acceptable in yours and bellheim’s scenarios.

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Well it isn't really meant to be a work around. It is a complete hack because it messes with the file permissions via Samba.

    It is a very temporary bandaid.

    The bug needs to be fixed on the SyncToy side in the way it deals with creating read-only files.

    You are right. Some of us had reproduced this issue and are deeply investigating it. I hope they can bring you good news.

    Thanks
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, January 7, 2010 2:39 AM
  • Hi!

    I have the same results like AcesOver: The option 'delete readonly' does not work. Temporary it works with "force create mode = 700".

    bellheim
    Thursday, January 7, 2010 1:11 PM
  • Hi Bellheim,

    With some experiments, this seems to be something related with the samba share you are using ( I assuemd this by reading the syncToy log file provided above), I can even repro this simply by renaming a READONLY files when epening the share with explorer.exe on the Windows machine.

    I just tried using NFS shares to do this and it can be used as a workaround. here is what I did:

    Assume you have the file struction like this /home/test/ on the Linux and /home is the NAS drive and test is the target folder.

    1. on the linux box, ensure the nfs service is running, and configure and export /home

    2. on the windows machine, mount the exported linux drive, say :

        Mount \\<linux IP>\home *
              T: is now successfully connected to \\<linux IP>\home
    3. configure the syncToy, set the right folder as T:\home\test

    this worked fine based on my experience, would you try this out to see if this worked with you under your envrioment ?

    Thanks
    Yunwen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, January 9, 2010 2:40 AM
    Moderator
  • Hi Yunwen!

    I use Vista Home and there is no onboard possibility to mount a NFS share. I will search for a solution using NFS at Vista Home.

    Thanks,
    Derk
    Saturday, January 23, 2010 10:36 AM
  • I am having exactly the same problem. 
    I am using Windows 7 Ultimate, SyncToy 2.1 and Debian Linux based NAS (running Samba)
    I am in the process of setting up some backup infrastructure following my upgrade from XP to Win7.

    I am very happy I found this thread. It would never have occurred to me to check on the Read Only attribute on the source file as causing an access denied violation on the destination. I had this failure with 4 files out of a set of over 10,000.

    Interestingly, robocopy did not exhibit this same issues.

    In my case I just removed the Read Only setting and the next pass of SyncToy picked up the files and Sync'd them just fine.
    I guess I will be waiting for SyncToy 2.2.
    Monday, January 25, 2010 5:15 AM
  • I'm having the same issue. I'm copying from one NAS to another (one is a Lacie MiniDisk and the other is a Buffalo Linkstation). I'm using XP SP3 to initiate the transfer and I'm trying to do a synchronize between the Lacie and the Buffalo.  Files are attempting to move from the Lacie to the Buffalo.

    If I use file manager to do the copies, I have no problems.

    None of the files attempted are marked read only.

    Save overwritten files is disabled.

    Have attempted to mount the Buffalo as a mounted drive - same result.

    Using SyncToy 2.1

    Interestingly enough, if I use Windows 7 to do the same operation (typically moves files from the Buffalo to the Lacie), I have no problems.

    Please let me know if I can help in troubleshooting!

    Monday, February 8, 2010 6:58 PM
  • As a kludge for this, I wonder if it would be possible to run a script that removes the read-only flag, runs SyncToy, then (if you need them to be) puts the read-only flag back on the affected files?   You would need to read in the file list, pull the filenames with the read-only flag into an array,  unset the flags, run SynchToy, wait for it to be complete, and then set the flags back on for each filename in the array, if you need them to stay read-only.
    Of course, I can't give you an example here, but I thought I might throw that in as a possible work-around.  Maybe someone else would know how to easily do this.  If I get some time, I might try doing it, but it's unlikely that I'll have the time.  <grin>
    Friday, February 12, 2010 4:25 PM
  • I seem to be having similar problem - access denied'.

    I was earlier using Windows XP. Now I have upgraded to Windows7 Home Premium.

    In the earlier version (XP), SyncToy worked well.

    Now with Windows7, it rejects many folders/files with error message 'access denied'.

    I had to physically copy the affected folders/files. While copying, I was asked for 'administrator's permission'.

    I am the user and administrator

    How to overcome this?

    Thursday, March 25, 2010 2:51 AM
  • I think I have overcome the problem of 'access denied' reported in the previous post.

    I invoked the privilege level option to 'Run as Administrator' in the 'Properties-Compatibiliy'.

    It seems to be working.

    Thanks for your time.

    V Govindan

    Thursday, March 25, 2010 5:05 AM
  • I think I have overcome the problem of 'access denied' reported in the previous post.

    I invoked the privilege level option to 'Run as Administrator' in the 'Properties-Compatibiliy'.

    It seems to be working.

    Thanks for your time.

    V Govindan


    Could you provide a bit more information on your workaround? Specifically, did you start the executable with a "Run As..." command? If so, then your paired folders setup as another user don't show up, and there could be a problem with multiple users sync-ing the same files (not recommended by SyncToy documentation).

    In my specific case, I get this error:

    Error: Cannot write to the destination file. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Copying \\nas1\share\larry\Synchronize\My Web Sites\site\_vti_pvt\service.cnf to \\nas2\share\larry\Synchronize\My Web Sites\site\_vti_pvt\service.cnf 
    
    SyncToy action was 'Synchronize'. SyncToy options were: Active for run all All files included No files excluded Do not check file contents Include read-only files Include hidden files Include system files Do not backup older files All subfolders included

     

    and I seem to have problems with 'system' type files. For example, files contained in the "_vti_pvt" and "_vti_pvt" folders created by Microsoft Expressions 3 will generate this error when a synchronization is attempted. The attempted synchronization is between two NAS boxes on separate sub-nets. That is, one NAS is on 192.168.0.xxx and the other is on 192.168.1.xxx . The "Read Only" attribute is not set on either the source or destination. The option to 'recycle' the replaced file is not set. Replacing the files using a Windows Explorer command (copy/paste) works just fine. Using SyncToy 2.1 and the user has Administrator privileges (SyncToy running on an x32 WinXP machine).

    • Proposed as answer by Govindan Monday, March 29, 2010 5:31 PM
    Monday, March 29, 2010 1:52 PM
  • I think I got the same kind of error message which you have reproduced. But in my case, I was not interestred in System files, but only data files.

    As I had brought out, In the 'Properties-compatibility' dialog, I checked the box the 'Run as administrator'. And, I now have no problem with SyncToy.

    I inadvertently pressed 'Propose As Answer' to the previous post. Sorry,

    V Govindan

     

    Monday, March 29, 2010 5:34 PM
  • Govindan, thank you kindly for your prompt and helpful reply.

    Unfortunately, on WinXP-SP3 that I'm using, I don't have this checkbox in my Properties-Compatibility tab dialog. Only Compatibility mode settings, Display settings, and Input settings.

    I can get a similar functionality,though, by using the "Properties", "Shortcut" tab, "Advanced..." Button and in the pop-up Advanced Properties dialog, I can click a box that says "Run with different credentials. Then, when I try and run SyncToy, I'm prompted for the u/n and p/w for the new credentials (which I can enter as Administrator). Then, the program does not see any of the folder pairs that I have set-up using my normal credentials/log-in.

    If I setup my administer account with the same folder pairs (and re-specify new login credentials on the NAS boxes for the Administrator account), then I'm right back where I started with 'system' files not being able to be overwritten. I guess this makes sense as my original credentials were Administrator-group level.

    Thank you again for your clarification. I'm just going into the results ad-nauseum for the MSFT admins so that they might be able to isolate this issue. I wish your fix had worked for me!

    Monday, March 29, 2010 9:47 PM
  • >It appears the problem is on the SyncToy side with read-only files.

    I can confirm this. On some NAS drives Linux-operated (like mine), Synctoy tries to set-up the RO flag but can't. I don't care about the attributes (RO, Archive...), this could be an option in Synctoy ?!?

    Moreover, would it be possible to "serialize" file copy instead of using multiple threads which, in a Wifi network environment, are not very efficient ?


    Schneider Electric Industries France
    Monday, June 21, 2010 7:19 AM
  • We're into 2011 now.  :-)  Any news on a fix for this?

    I tried SyncToy for the first time today (in echo mode, Win XP SP3 --> a home-brew NAS running CentOS Linux and Samba), and everything worked perfectly, except for 12 of the 4,000-odd files, which I noticed were all read-only - I hit this issue, in other words.

    I've checked, and there's no general problem with the Windows PC changing file attributes/permissions on the NAS filestore.  Indeed, if I take the read-only flag off one of my 'problem' files, SyncToy copies it over fine (of course) and I can then run 'ATTRIB +R' on the remote copy of the file, from the Windows PC, and that works.

    So many people will be using the tool to backup/sync with a Linux/Samba-based NAS, so a fix for this is getting urgent.  The 'answer' post concerns the use of NFS, which is no use to 'normal' Windows users.  This is still an open issue, IMHO.

    Many thanks for a great little utility nonetheless.

    Cheers  Andy

     

    Friday, February 4, 2011 12:39 PM
  • Time marches on - and I've come to some conclusions as to what is going on based on my experiences with WinXP and Win7 systems trying to read/write to Debian / Linux / systems. The problems I am seeing all relate to the permissions of the files on NAS drives being assigned improperly by SyncToy 2.1.

    For example, check out these scenarios:

    1. creating a new file on my LaCie MiniDisk using Win7 Explorer, the owner becomes "root" (the master login user name on the LaCie). It is created "Full control" permissions for 'root'.
    2. Creating a new file on my Buffalo Linkstation using Win7 Explorer, the owner becomes "nobody" (which has "Full control" permissions).
    3. Running SyncToy 2.1 Synchronize, the originally created files are copied to the opposite drives. The File that was owned by 'root' on the LaCie drive copied over to the Buffalo drive with the owner 'nobody'. However, 'nobody' now does not have full permissions on the file. Delete permissions are missing. "Full control" permission for 'nobody' is no longer present on this file.
    4. The file that was originally created on the Buffalo Linkstation is created on the LaCie drive with the Synch operation. It has the owner 'root' as all the other files on the LaCie have. However, the 'Full control' permission for 'root' has been lost. So has the Delete permission.
    5. If I create a file on one drive, and use Win7 Explorer to manually copy the file to its synchronize location on the other NAS, "Full control" permissions are retained on the copied drive.

    Conclusion: If SyncToy copies the file, permissions are dropped on the copy. If Win7 Explorer copies the file, permissions are retained. A SyncToy copy is not the same as an Explorer copy.

    Permissions are being dropped when SyncToy moves files from one NAS to the other NAS. Specifically, the "Full control" permission and the "delete" permissions are not being set when the files are created by SyncToy on the non-original drive.

    This loss of permissions causes all kinds of grief when SyncToy later tries to rename, delete, or move a file created by SyncToy 2.1.

    I'm not seeing or hearing much in the way of development work on a SyncToy 2.1+. This is dissappointing as it seems like it is very close to being a usable tool. Right now, I have thousands and thousands of files I would have to manually delete/rename to keep these two NAS drives synchronized. I'm giving up on SyncToy and looking for an alternative.

     



    Friday, May 20, 2011 3:27 PM