Discussion:
File permissions/ownership on XP systems
(too old to reply)
Roger Mills
2018-04-27 13:58:43 UTC
Permalink
I'm having problems creating files from across my LAN to a shared drive
on a Win XP system. In the properties for the shared folder, the "allow
network users to change my files" box is checked.

There is no problem if I edit a file, and save the updated version. But
if I try to do a "Save as" - which creates a new file rather than
updating an existing one - it objects. I get an error message saying
"This security ID may not be assigned as the owner of this object"

I first noticed it when using RoboCopy across my network from a Win 7
laptop to the XP desktop. When we go away from home, we copy selected
folders from the XP system to the laptop in order to work on them while
away. When we return, we copy changed and new files back, using
RoboCopy. I've noticed recently that any updated files get copied back
ok, but any new ones don't - with an error which says:

"ERROR 1307 (0x0000051B) Copying File {filename} This security ID may
not be assigned as the owner of this object" [Which is obviously the
same basic problem as described above]

I'm pretty sure that it had used to work, but I can't work out what has
changed. I'm not sure whether it's an XP issue or a W7 issue. Any clues?
What and where do I need to set or change permissions to make this work
properly?
--
Cheers,
Roger
____________
Please reply to Newsgroup. Whilst email address is valid, it is seldom
checked.
Paul
2018-04-27 14:52:04 UTC
Permalink
Post by Roger Mills
I'm having problems creating files from across my LAN to a shared drive
on a Win XP system. In the properties for the shared folder, the "allow
network users to change my files" box is checked.
There is no problem if I edit a file, and save the updated version. But
if I try to do a "Save as" - which creates a new file rather than
updating an existing one - it objects. I get an error message saying
"This security ID may not be assigned as the owner of this object"
I first noticed it when using RoboCopy across my network from a Win 7
laptop to the XP desktop. When we go away from home, we copy selected
folders from the XP system to the laptop in order to work on them while
away. When we return, we copy changed and new files back, using
RoboCopy. I've noticed recently that any updated files get copied back
"ERROR 1307 (0x0000051B) Copying File {filename} This security ID may
not be assigned as the owner of this object" [Which is obviously the
same basic problem as described above]
I'm pretty sure that it had used to work, but I can't work out what has
changed. I'm not sure whether it's an XP issue or a W7 issue. Any clues?
What and where do I need to set or change permissions to make this work
properly?
There's a suggestion here.

https://serverfault.com/questions/236963/robocopy-failure-with-windows-server-2008-scheduled-task

"The account used to perform the copy must have the
"Restore files and directories" user right to change the owner
to anything other than itself or Administrators.

http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc783530%28v=ws.10%29

Ownership

Ownership can be taken by the following: ...
"

I only picked this, because you're using Robocopy, and maybe you're
using Task Scheduler or something to drive it.

Paul
Roger Mills
2018-04-27 17:13:30 UTC
Permalink
Post by Paul
Post by Roger Mills
I'm having problems creating files from across my LAN to a shared
drive on a Win XP system. In the properties for the shared folder, the
"allow network users to change my files" box is checked.
There is no problem if I edit a file, and save the updated version.
But if I try to do a "Save as" - which creates a new file rather than
updating an existing one - it objects. I get an error message saying
"This security ID may not be assigned as the owner of this object"
I first noticed it when using RoboCopy across my network from a Win 7
laptop to the XP desktop. When we go away from home, we copy selected
folders from the XP system to the laptop in order to work on them
while away. When we return, we copy changed and new files back, using
RoboCopy. I've noticed recently that any updated files get copied back
"ERROR 1307 (0x0000051B) Copying File {filename} This security ID may
not be assigned as the owner of this object" [Which is obviously the
same basic problem as described above]
I'm pretty sure that it had used to work, but I can't work out what
has changed. I'm not sure whether it's an XP issue or a W7 issue. Any
clues? What and where do I need to set or change permissions to make
this work properly?
There's a suggestion here.
https://serverfault.com/questions/236963/robocopy-failure-with-windows-server-2008-scheduled-task
"The account used to perform the copy must have the
"Restore files and directories" user right to change the owner
to anything other than itself or Administrators.
http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc783530%28v=ws.10%29
Ownership
Ownership can be taken by the following: ...
"
I only picked this, because you're using Robocopy, and maybe you're
using Task Scheduler or something to drive it.
Paul
Thanks for your reply, Paul.

I had seen some of this stuff when Googling the problem, but don't
really understand it. Most of the stuff it refers to only applies to
Server-2003 or XP-Pro - and I am using XP-Home!

I'd also seen the bit which you quote about "The account used to perform
the copy must have the "Restore files and directories" user right to
change the owner to anything other than itself or Administrators."

But it doesn't give any clues as to how - or where (i.e. on the XP or W7
system in my case) - to set this.

Any further ideas?
--
Cheers,
Roger
____________
Please reply to Newsgroup. Whilst email address is valid, it is seldom
checked.
Paul
2018-04-27 20:04:33 UTC
Permalink
Post by Roger Mills
Post by Paul
Post by Roger Mills
I'm having problems creating files from across my LAN to a shared
drive on a Win XP system. In the properties for the shared folder, the
"allow network users to change my files" box is checked.
There is no problem if I edit a file, and save the updated version.
But if I try to do a "Save as" - which creates a new file rather than
updating an existing one - it objects. I get an error message saying
"This security ID may not be assigned as the owner of this object"
I first noticed it when using RoboCopy across my network from a Win 7
laptop to the XP desktop. When we go away from home, we copy selected
folders from the XP system to the laptop in order to work on them
while away. When we return, we copy changed and new files back, using
RoboCopy. I've noticed recently that any updated files get copied back
"ERROR 1307 (0x0000051B) Copying File {filename} This security ID may
not be assigned as the owner of this object" [Which is obviously the
same basic problem as described above]
I'm pretty sure that it had used to work, but I can't work out what
has changed. I'm not sure whether it's an XP issue or a W7 issue. Any
clues? What and where do I need to set or change permissions to make
this work properly?
There's a suggestion here.
https://serverfault.com/questions/236963/robocopy-failure-with-windows-server-2008-scheduled-task
"The account used to perform the copy must have the
"Restore files and directories" user right to change the owner
to anything other than itself or Administrators.
http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc783530%28v=ws.10%29
Ownership
Ownership can be taken by the following: ...
"
I only picked this, because you're using Robocopy, and maybe you're
using Task Scheduler or something to drive it.
Paul
Thanks for your reply, Paul.
I had seen some of this stuff when Googling the problem, but don't
really understand it. Most of the stuff it refers to only applies to
Server-2003 or XP-Pro - and I am using XP-Home!
I'd also seen the bit which you quote about "The account used to perform
the copy must have the "Restore files and directories" user right to
change the owner to anything other than itself or Administrators."
But it doesn't give any clues as to how - or where (i.e. on the XP or W7
system in my case) - to set this.
Any further ideas?
As Administrator I presume:

control userpasswords2

It looks like this, but I cannot vouch for which "group"
value, added to a restricted account, would give the
desired result.

Loading Image...

The "Backup Group" is supposed to be the group that
you add so an ordinary user can run backups (which
capture files from all different accounts). So in the
example image, it's the closest thing I can think of.

And all the picture does, is illustrate the concept for
WinXP. It's not a guarantee I understand this stuff :-)

The thing is, something run from Task Scheduler is supposed
to be run with SYSTEM account privilege. Which isn't even
listed in that dialog. Usually a Task Scheduler also contains
an option to run as some other account. One of the reasons
some people (ab)use Task Scheduler, is just so a command
can run as SYSTEM. But it doesn't guarantee that Robocopy
will be doing the right thing.

Robocopy also has options for controlling what is
copied, like "datso" for NTFS. Which is supposed to
"preserve stuff".

Now, you have a metric ton of options, none of which
is "convincingly good".

The system that picture was taken from is a bit different,
in that the WinXP is installed on FAT32, and not NTFS. Whether
that affects the account items shown, is just another
variable.

Paul
Roger Mills
2018-04-27 22:14:26 UTC
Permalink
Post by Paul
Post by Roger Mills
Post by Paul
Post by Roger Mills
I'm having problems creating files from across my LAN to a shared
drive on a Win XP system. In the properties for the shared folder, the
"allow network users to change my files" box is checked.
There is no problem if I edit a file, and save the updated version.
But if I try to do a "Save as" - which creates a new file rather than
updating an existing one - it objects. I get an error message saying
"This security ID may not be assigned as the owner of this object"
I first noticed it when using RoboCopy across my network from a Win 7
laptop to the XP desktop. When we go away from home, we copy selected
folders from the XP system to the laptop in order to work on them
while away. When we return, we copy changed and new files back, using
RoboCopy. I've noticed recently that any updated files get copied back
"ERROR 1307 (0x0000051B) Copying File {filename} This security ID may
not be assigned as the owner of this object" [Which is obviously the
same basic problem as described above]
I'm pretty sure that it had used to work, but I can't work out what
has changed. I'm not sure whether it's an XP issue or a W7 issue. Any
clues? What and where do I need to set or change permissions to make
this work properly?
There's a suggestion here.
https://serverfault.com/questions/236963/robocopy-failure-with-windows-server-2008-scheduled-task
"The account used to perform the copy must have the
"Restore files and directories" user right to change the owner
to anything other than itself or Administrators.
http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc783530%28v=ws.10%29
Ownership
Ownership can be taken by the following: ...
"
I only picked this, because you're using Robocopy, and maybe you're
using Task Scheduler or something to drive it.
Paul
Thanks for your reply, Paul.
I had seen some of this stuff when Googling the problem, but don't
really understand it. Most of the stuff it refers to only applies to
Server-2003 or XP-Pro - and I am using XP-Home!
I'd also seen the bit which you quote about "The account used to
perform the copy must have the "Restore files and directories" user
right to change the owner to anything other than itself or
Administrators."
But it doesn't give any clues as to how - or where (i.e. on the XP or
W7 system in my case) - to set this.
Any further ideas?
control userpasswords2
It looks like this, but I cannot vouch for which "group"
value, added to a restricted account, would give the
desired result.
https://s31.postimg.cc/mzm9a4a5n/userpasswords2.gif
The "Backup Group" is supposed to be the group that
you add so an ordinary user can run backups (which
capture files from all different accounts). So in the
example image, it's the closest thing I can think of.
And all the picture does, is illustrate the concept for
WinXP. It's not a guarantee I understand this stuff :-)
The thing is, something run from Task Scheduler is supposed
to be run with SYSTEM account privilege. Which isn't even
listed in that dialog. Usually a Task Scheduler also contains
an option to run as some other account. One of the reasons
some people (ab)use Task Scheduler, is just so a command
can run as SYSTEM. But it doesn't guarantee that Robocopy
will be doing the right thing.
Robocopy also has options for controlling what is
copied, like "datso" for NTFS. Which is supposed to
"preserve stuff".
Now, you have a metric ton of options, none of which
is "convincingly good".
The system that picture was taken from is a bit different,
in that the WinXP is installed on FAT32, and not NTFS. Whether
that affects the account items shown, is just another
variable.
Paul
Thanks again, Paul. It all sounds very complicated!

I suspect that I'm missing something simple, somewhere along the line.
To some extent, Robocopy may be a red herring. True, that's where I
first noticed the problem. But I get exactly the same error when I use
Windows Explorer et al to copy a new file, as opposed to an updated
file, to the XP system.

I'm sure that if I could make a simple copy work, the Robocopy stuff
would work, too.

Anyone else got any ideas?
--
Cheers,
Roger
____________
Please reply to Newsgroup. Whilst email address is valid, it is seldom
checked.
Paul
2018-04-28 00:59:09 UTC
Permalink
Post by Roger Mills
Post by Paul
Post by Roger Mills
Post by Paul
Post by Roger Mills
I'm having problems creating files from across my LAN to a shared
drive on a Win XP system. In the properties for the shared folder, the
"allow network users to change my files" box is checked.
There is no problem if I edit a file, and save the updated version.
But if I try to do a "Save as" - which creates a new file rather than
updating an existing one - it objects. I get an error message saying
"This security ID may not be assigned as the owner of this object"
I first noticed it when using RoboCopy across my network from a Win 7
laptop to the XP desktop. When we go away from home, we copy selected
folders from the XP system to the laptop in order to work on them
while away. When we return, we copy changed and new files back, using
RoboCopy. I've noticed recently that any updated files get copied back
"ERROR 1307 (0x0000051B) Copying File {filename} This security ID may
not be assigned as the owner of this object" [Which is obviously the
same basic problem as described above]
I'm pretty sure that it had used to work, but I can't work out what
has changed. I'm not sure whether it's an XP issue or a W7 issue. Any
clues? What and where do I need to set or change permissions to make
this work properly?
There's a suggestion here.
https://serverfault.com/questions/236963/robocopy-failure-with-windows-server-2008-scheduled-task
"The account used to perform the copy must have the
"Restore files and directories" user right to change the owner
to anything other than itself or Administrators.
http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc783530%28v=ws.10%29
Ownership
Ownership can be taken by the following: ...
"
I only picked this, because you're using Robocopy, and maybe you're
using Task Scheduler or something to drive it.
Paul
Thanks for your reply, Paul.
I had seen some of this stuff when Googling the problem, but don't
really understand it. Most of the stuff it refers to only applies to
Server-2003 or XP-Pro - and I am using XP-Home!
I'd also seen the bit which you quote about "The account used to
perform the copy must have the "Restore files and directories" user
right to change the owner to anything other than itself or
Administrators."
But it doesn't give any clues as to how - or where (i.e. on the XP or
W7 system in my case) - to set this.
Any further ideas?
control userpasswords2
It looks like this, but I cannot vouch for which "group"
value, added to a restricted account, would give the
desired result.
https://s31.postimg.cc/mzm9a4a5n/userpasswords2.gif
The "Backup Group" is supposed to be the group that
you add so an ordinary user can run backups (which
capture files from all different accounts). So in the
example image, it's the closest thing I can think of.
And all the picture does, is illustrate the concept for
WinXP. It's not a guarantee I understand this stuff :-)
The thing is, something run from Task Scheduler is supposed
to be run with SYSTEM account privilege. Which isn't even
listed in that dialog. Usually a Task Scheduler also contains
an option to run as some other account. One of the reasons
some people (ab)use Task Scheduler, is just so a command
can run as SYSTEM. But it doesn't guarantee that Robocopy
will be doing the right thing.
Robocopy also has options for controlling what is
copied, like "datso" for NTFS. Which is supposed to
"preserve stuff".
Now, you have a metric ton of options, none of which
is "convincingly good".
The system that picture was taken from is a bit different,
in that the WinXP is installed on FAT32, and not NTFS. Whether
that affects the account items shown, is just another
variable.
Paul
Thanks again, Paul. It all sounds very complicated!
I suspect that I'm missing something simple, somewhere along the line.
To some extent, Robocopy may be a red herring. True, that's where I
first noticed the problem. But I get exactly the same error when I use
Windows Explorer et al to copy a new file, as opposed to an updated
file, to the XP system.
I'm sure that if I could make a simple copy work, the Robocopy stuff
would work, too.
Anyone else got any ideas?
If this is a data partition, and not C: as your destination,
could you do a TakeOwn ?

https://www.sevenforums.com/tutorials/1911-take-ownership-shortcut.html

"The Take Ownership context menu will not be available when you
right click on the C: drive, C:\Program Files folder,
C:\Program Files (x86) folder, C:\ProgramData folder,
C:\Users folder, and C:\Windows folder. This was done because
taking ownership of these system folders can make Windows unstable"

takeown /f "%1" && icacls "%1" /grant *S-1-3-4:F /c /l

It's possible WinXP is missing those commands, so there would
be some equivalents of that, which use different utilities.

You can also do properties and look at the Security tab and
check the ownership there. Keeping in mind, there is an "Inherit"
property to transfer the security info from a folder above where
you currently are. As well as "Allow" and "Deny" capabilities
for the permissions. The usage of "Deny" is not considered
a "best practice" when designing permissions. Generally it's
Allow or Not Allow (as seen by tick boxes in the security tab).

On many occasions, I've been *stumped* by what is blocking
a transfer - I can stare at that information for hours and
not figure out what blocks a transfer. Let's hope you have
better luck.

One "IT guy" technique, is to use "icacls" to log the
permissions on the volume, "smash" the permissions, then
use the permission restoration function of icacls in
playback mode (using the log file as a source of
permission info), to put the permissions back as they were
originally. The only thing that won't get corrected of
course, is anything which is "new" to the partition, there
would be no record of the "best" permissions for that. Again,
this technique isn't intended for any "known sensitive areas"
of C: . If you want to mess with dangerous spots, doing
the operation "offline" from a WinPE boot CD might be an option.

http://dandar3.blogspot.ca/2013/01/how-to-ntfs-compress-windows-winsxs.html

There is a small problem with the syntax of icacls when restoring
all the way from the top of D:\ . This article touches on it,
but doesn't address the issue. The individual here, is restoring
permissions on D:\DATA. He can " cd /d D: " for example and
be CD'ed above the directory, and the command works to restore
DATA to the way it was. However, this article doesn't describe
how one "CDs above D: ".

https://blogs.technet.microsoft.com/askds/2008/11/24/how-to-back-up-and-restore-ntfs-and-share-permissions/

The answer to that, is to edit the ntfsperms.txt log file. If
you log the permissions all the way from D: downwards (with /t /c),
the first line of the file is blank

<blank line...>
perms_of_top_level_of_D_are_here

If you edit the text file, and change the first line to ".", as
in current working directory, this is supposed to correct the
issue. The person playing back the permissions does "cd /d D: "
and then when playing back, the second line applies to D: itself.

.
perms_of_top_level_of_D_are_here
DATA
perms_of_DATA_folder are here

Paul
Mayayana
2018-04-28 01:04:41 UTC
Permalink
"Roger Mills" <***@gmail.com> wrote

| Anyone else got any ideas?

If it were me I'd share everything on a FAT32
partition. I don't see any reason to fiddle with
permissions hassles outside of a system that
needs restrictions, like corporat or gov't computers.

But that may not be a useful idea for you. I
don't know who's on your LAN. For that matter,
I don't see any reason to have the security risks
of a LAN. The rare times when I want to put
a file on another computer I just walk down
the hall with a USB stick.

Loading...