Hi all, I just wanted to hear whether there is any plan to implement a --local-ingore-access flag as hinted at in this response to one of my previous support requests. We are seeing some more errors such as this:
2021/05/03 14:30:21 ERROR : path/to/file.txt: Failed to copy: failed to open source object: Access is denied.
There are no special permissions on this file. It is a Windows Server 2012 machine.
i think you mean --local-ignore-access
not sure it will help, as i workaround it.
i have a script for backup that runs, VSS, rclone, 7z, fastcopy and veeam.
they all produce logs and the script parses thru them looking for errors and specific text.
then the script makes a report and emails it to me.
if there is a particular error message that i am not interested in, the script does not report it.
Thanks @asdffdsa, yes, I think we refer to the same flag name --local-ingore-access, unless I'm missing some difference between your spelling and mine 
At this stage, I can only rely on the rclone output and thus I would greatly appreciate the ability for rclone to ignore such access denied errors. I am also using VSS in the background as per your wiki, to try to avoid any file in use related errors, but this access denied one has me stumped. I can't figure out why it's happening and it would be super useful if rclone could ignore it...
what is the name of the file?
It is a .xlsx file, an Excel file
what are the user permissions for that file?
Hmm, I don't have access to this machine myself, will need to see if the administrator can check for me. But as far as I understand, the permissions are no different than those of other files which are successfully being backed up...
well, seems like a windows permisisons issue.
can you copy the file not using rclone?
--local-ingore-access - must be a typo?
It would seem so yes, but rclone is being run from a Windows service with System privileges.
I will try to get an idea what the permissions are on this file and whether it can be manually copied...
not sure what that means? yes, no, not tested?
can another executable access the same file, using the same user privileges are rclone?
Sorry, the first part of my answer (It would seem so yes) was regarding the statement that it seems to be a Windows permissions error, not an answer to the question about whether one can make a copy of the file while not using rclone. I will try to find that out...
Seems it may be a password protected Excel file... In any case, the abovementioned flag would be helpful!
What would you want that flag to do?
In general if you have a file and you couldn't sync it then rclone returns an error. So a --local-ingore-access file could return a different error.
I think what you want is something like --skip-unreadable. What that might do is figure out whether a file is readable by rclone and if not leave it out of the sync completely. This would enable rclone to complete the sync with no errors.
To do this test reliably rclone would have to Open every file in the listing read only to check it can actually open them. This might slow things down a bit. There might be a better way of doing that, I'm not sure.
Doing the check when rclone opens the object is too late unless we add a special ignore error class which isn't impossible but we don't have it at the moment!
Hi @ncw , yes, the name of the flag was just an example as per what you mentioned as an option in a previous discussion about the problem (see the link in my post above). You're right, the behaviour I would want is as you describe for a --skip-unreadable flag, in other words, that files which are not accessible are simply skipped and no error is given. My inclination would be towards the latter implementation option which you describe, i.e. where rclone skips the file only once it tries to open the object and cannot open it for whatever reason. It would seem to me a faster and more robust way to handle this...
Just some food for thoughts:
Assume a --skip-unreadable/--ignore-access flag is set on a sync and there is an unforeseen situation where rclone is unable to read any of the source files. Then the sync reports everything OK after having deleted all of the destination files.
Unforeseen situations could be changed access rights on the destination, disk errors, a bug in rclone etc. etc. The flag is therefore somewhat similar to cutting the wire to the "defective brakes" lamp in your car display.
Personally I prefer treating all unforeseen/unexplained situations like errors/exceptions to be handled and wouldn’t dare using such a flag.
I suppose you're right in a way... However, if I have a very large set of files to backup, I cannot know up-front which of those may be inaccessible to rclone in order to manually exclude them, and although I may want to have a warning log message when such a file is encountered, I would also like the ability to let rclone not return with an error code after all but a few inaccessible files have been transferred. I agree, this shouldn't be the default, but as an option it would be helpful. At least in my view that is the other side of the coin...
I guess everything is backed up except the failing files, so if you don’t mind a few skipped files then everything is already fine without need for an extra sync with an ignore flag?
For your inspiration: I have a script, that upon rclone error filters out the ERROR lines in the log and sends me a mail with them. This allows me to quickly decide if the errors can be ignored or action is needed. Filters, access rights and user behaviour are continuously adjusted to reduce the number of mails
Yeah, I get it. I've just been trying to avoid doing this since I cannot do it manually like you do. I'd need to parse the logs programmatically and build in logic to determine which errors or combinations of errors would require attention and which not. So I just hoped I could rely on the rclone exit code instead...
If it is generally agreed that my way would be wrong, then so be it, I'll need to accept that:)
I don't have a problem with adding another flag if someone wants to have a go. But, yes, ignoring errors can lead to problems!
And just to explain a bit more where I'm coming from: the rclone command is already running with the highest privileges possible on a Windows system, thus, when encountering an access denied error, there's nothing else to be done but to exclude or to ignore (or maybe to stop using Windows...)
It would be quite a pain to have to continuously adjust the filters as we find inaccessible files/folders rather than to just ignore those specific errors.
In any case, I agree that as a general rule ignoring errors is not advisable.