Problem with setting file attributes on MBL

I’ve been setting up backup and mirror jobs between my MBL and my local drive, based on robocopy.

I’m running up against issues in a situation where the backup script needs to change an attribute of the files on the MBL.  This happens when when I use the Archive attribute bits of files in order to keep track of what has been backed up and what hasn’t (the robocopy option /M is relevant here).

The trouble comes when I run the script as me (I have admin privileges), and the backup script is backing up another user’s files from the MBL to the local drive.  Now, on the MBL I have read and write access to all users’ shares, so accessing those files for backing up is not a problem.  

The problem comes when robocopy tries to reset the Archive attribute bit of a file on the MBL after backing it up.  In particular, where that file was created by another user on the MBL other than me.  Robocopy gives an Error 5 – access not permitted – error when trying to update the file attribute.

This is a long-winded way of saying:

Although I have read / write access to all other users’ files on my MBL, and can edit / delete any file created on the MBL by any user, I do not seem to be able to change the file attributes of any file which wasn’t created by me.

This seems a bit off – I can edit / trash another user’s file, but I cannot change a file attribute for that file.

Is there any way around this?  Preferably a way in which I can force an appropriate level of authority on the robocopy command (and the attrib command) to allow it to change the file attribute of another user’s file? 


Well, Linux doesn’t have an archive bit. So I have no idea what Robocopy thinks it’s doing with that attribute.

Samba can map those special DOS attribute bits to the EXECUTE bits in the Linux filesystem, but you’ll have to modify the samba configuration to do that…

Regardless of whether linux has an archive bit, windows / vista does.  Right click on a file stored on the MBL, go to properties, and you can set / reset the archive bit just fine.  You can also set / reset the archive bit using the attrib command, and via robocopy /m.  That is, until you try to do that to someone else’s file on the MBL. 

So it doesn’t seem to me to be an issue with linux not having archive bits, and more a permissions / access control issue.

In linux, only the owner of a file can change its attributes, and the MBL does run Linux.

And yes, the ARCHIVE bit mapping is enabled by default in Samba, so that explains how that’s working…

I should imagine that admin (or root) can also change the attributes of any file?  I’ve been trying to figure out ways of running the attrib or robocopy in windows such that the MBL considers the request to change attributes of a file as coming from an admin (or root), rather than the actual user logged on and running the command.  (Opening the cmd window as an admin, or running the batch file as an admin, doesn’t seem to do it.)

Anyone with some knowledge of how that could be done?  E.g. there is a “runas” command, which I thought might enable me to run the attrib command as “MyBookLive\root” or something similar.  I don’t know enough to know whether this might be possible.

I dunno…   If you’re determined to back up a Linux-based NAS using an older DOS method, I think you’re going to have a hard time.  I would just suggest you look for a more modern method to recognize changed files, like RSYNC or something similar.

The DOS Archive bit has been deprecated even in Windows systems; Vista included it only for backward compatibility for XP.   Windows 7 has abandoned its use.   The bit is still there, but the O/S no longer modifies it when the file is changed.

The privileges invoked on a Windows box (running as Admin) has absolutely no effect on what user is logged into the Samba share.   

In order to have “root’s” privileges on the NAS, you have to log into that Samba Share as root, and I don’t think the MBL allows that.  Other NAS’s do.

But even then, root is only allowed to change the attributes of files owned by “root.”   That’s a SAMBA thing, not a Linux or WD or Windows thing.

There is something else installed on the Linux OS within the MyBook Live which improves on the native user and file permissions. That could be the problem.  (At least I believe this is the case. Will have to double check.)

Myron – interesting.  Look forward to your follow-up.  Would there be any solution to that problem?  I find it difficult to believe that there isn’t a way of having an admin on the windows platform, with the highest privileges possible, perform attribute-related functions on files of ANY user on the NAS.  Performing backups of all user files on the NAS is just an example.  Otherwise it’s a serious limitation of hooking up a linux based NAS to a windows platform IMHO; this is not something I appreciated before buying a MBL and it may influence my decision as to whether or not to buy another one.

Yes there are ways other than using the archive bit to determine whether a file needs backing up.  The default is for robocopy just to compare source and destination files to see if the source is newer, and back up if so.  However, I’m trying to set up an incremental backup, to different destination folders each day, so that there aren’t any destination files to compare against for each incremental backup, only source files to inspect.  Use of the archive bits in the source files is actually quite a neat way to achieve this, though I guess there is concern about the longevity of such an approach if Win7 no longer bothers to set the archive bit on modification of a file.