File owned by "Unix User/nobody". Can't delete.

[John]

Hi,
I think the Subject line says it all?

NAS drive. Win-7. Some files are owned and locked by "Unix
User/nobody" and won't allow my Win-7 box to delete them. [Win-7
Ultimate].

I've tried DOS Command Prompt, changing the permissions, changing
the owner, using the remote management web interface and thinking
about crying.

That last would of course make me feel better but would not really
affect the files.

I've even used PowerShell "Remove-Item *.* -Force" inside the
folder or directory holding the files.

No, I've no idea *how* "NOBODY" got hold of the files.

MS Online support while exceedingly helpful doesn't have a fix for
this one, nor does the drive's manufacturer's website.

In PowerShell, the Get-ACl command tells me that the owner of the
files is someone called "O:S-1-22-1-65534". That's a little weird, but
I'll accept it as an "alias" of Mr. nobody.

The Help for Set-Acl is a little worrying. I'm not entirely sure
how I'd work it but I *think* I would

"C:\PS>$DogACL = get-acl Z:\dog.txt" to store the NAS file's
security inside an ACLObject then

"C:\PS>set-acl -path C:\cat.txt -AclObject $DogACL" to copy a
valid, friendly security description from a file I *know* I own into
the ACLObject for the one I don't.

But that would mean doing them one file at a time, so I *think*
these would be better:


"C:\PS>$newACL = get-acl file0.txt" from a file I *know* I own,
then

"C:\PS>get-childitem Z:\Folder -recurse -include *.* -force |
set-acl -aclobject $newacl" to set the contents of the NAS folder to
be owned by me.

But I've never used PS so I don't know what, if anything, the
drastic repercussions would be. Some gentle hand-holding would be very
much appreciated, thanks.

If it matters, it's a Seagate and I've deleted other stuff from it.
Any aid and comfort would be appreciated. :)

J.

[Paul]

Post by John
Hi,
I think the Subject line says it all?
NAS drive. Win-7. Some files are owned and locked by "Unix
User/nobody" and won't allow my Win-7 box to delete them. [Win-7
Ultimate].
I've tried DOS Command Prompt, changing the permissions, changing
the owner, using the remote management web interface and thinking
about crying.
That last would of course make me feel better but would not really
affect the files.
I've even used PowerShell "Remove-Item *.* -Force" inside the
folder or directory holding the files.
No, I've no idea *how* "NOBODY" got hold of the files.
MS Online support while exceedingly helpful doesn't have a fix for
this one, nor does the drive's manufacturer's website.
In PowerShell, the Get-ACl command tells me that the owner of the
files is someone called "O:S-1-22-1-65534". That's a little weird, but
I'll accept it as an "alias" of Mr. nobody.
The Help for Set-Acl is a little worrying. I'm not entirely sure
how I'd work it but I *think* I would
"C:\PS>$DogACL = get-acl Z:\dog.txt" to store the NAS file's
security inside an ACLObject then
"C:\PS>set-acl -path C:\cat.txt -AclObject $DogACL" to copy a
valid, friendly security description from a file I *know* I own into
the ACLObject for the one I don't.
But that would mean doing them one file at a time, so I *think*
"C:\PS>$newACL = get-acl file0.txt" from a file I *know* I own,
then
"C:\PS>get-childitem Z:\Folder -recurse -include *.* -force |
set-acl -aclobject $newacl" to set the contents of the NAS folder to
be owned by me.
But I've never used PS so I don't know what, if anything, the
drastic repercussions would be. Some gentle hand-holding would be very
much appreciated, thanks.
If it matters, it's a Seagate and I've deleted other stuff from it.
Any aid and comfort would be appreciated. :)

Yes, Nobody is a UID up near the end of the numeric space.

You are doing an operation against the file system on the NAS.
It is the NAS file-system-property that is causing the problem.
I doubt any amount of Powershell spell casting is going to work.
It's not the ACL that needs changing, it's the Owner of the file.

In these two examples, you can see some of the suggestions are quite different.
The first one (for some sort of container), is ridiculous.

https://unix.stackexchange.com/questions/563942/debian-change-owner-of-nobodynogroup

Something like chown (change owner) would be a start. Sudo gives you
root (administrator) permissions. On Windows, the equivalent would
be using an administrator terminal, and just doing the chown.

sudo chown 1000:1000 some.file # 500 is root, 1000 is the beginning of users
# This is similar on windows and linux.

Also, note the comment at the end of this thread, regarding smb.conf on Linux.
It's an attempt to prevent the use of nobody for a Guest operation.
(Mapping Windows Guest [a low-privilege account] to Unix/Linux Nobody)

https://forums.linuxmint.com/viewtopic.php?t=238139

smb.conf

guest account = {bullwinkle} # Many of my Linux installs use "bullwinkle" as the user.
# chown bullwinkle:bullwinkle some.file would be my command

But this might be done from the shell of the NAS box. The chown command.
Just mapping the Guest account to bullwinkle after the fact,
likely won't "fix" the inaccessiblity of a Nobody problem.

The NAS box won't know who bullwinkle is, but if you know
the UID of bullwinkle, then this form should always be accepted
(and will do something, as long as the number used is a useful value).
The NAS box will use simple numbers from 0..65535 .

chown 1001:1001 some.file

On Linux, a typical convenience, is to make the uid and gid the
same value, as in "USER bullwinkle : GROUP bullwinkle". Whereas
in the real world, they could be anything, such as bullwinkle:chessclub.
The group does not have to be the same, but by default and for the
convenience of new users, they are made similar to be "less scary".
On Unix we wouldn't do it that way, ever. The "group" on Unix,
always represented an organizational group and wasn't purely arbitrary.

For example, my Linux account frequently belongs to "vboxusers" group,
as part of using VirtualBox. And it belongs to "sambausers" group
for doing certain file sharing things. Making the group be "bullwinkle"
does not confer any special magical powers, which is likely why they're
doing it that way.

To get some info about your Windows account, try this in Administrator window.
The last cluster of digits on the end, is like a UID. The three larger
clusters (in a non-Domain setup) belong to the OS installation and are
randomly assigned. That's why "Paul" on computer #1 is not the same
as "Paul" on computer #2. Only when you're in a Domain, with a Domain
server to manage things, are you always authenticating against the
Domain and the string of digits should be the same as you move from
one Domain machine to another.

wmic useraccount get name,sid

So the problem, may have come from the mapping of Windows Guest,
to Linux Nobody, and on some computing device, you need to "Change Owner"
of the file, to try to fix it. And it might require the shell on the
NAS box, as I don't really know if you can wrangle this from Powershell.
If Powershell cannot be convinced to do something to a Guest item,
then you'd have to switch over to the controls on the NAS box
and try from that namespace.

Paul

[John]

Post by Paul

Post by John
Hi,
I think the Subject line says it all?
NAS drive. Win-7. Some files are owned and locked by "Unix
User/nobody" and won't allow my Win-7 box to delete them. [Win-7
Ultimate].
I've tried DOS Command Prompt, changing the permissions, changing
the owner, using the remote management web interface and thinking
about crying.
That last would of course make me feel better but would not really
affect the files.
I've even used PowerShell "Remove-Item *.* -Force" inside the
folder or directory holding the files.
No, I've no idea *how* "NOBODY" got hold of the files.
MS Online support while exceedingly helpful doesn't have a fix for
this one, nor does the drive's manufacturer's website.
In PowerShell, the Get-ACl command tells me that the owner of the
files is someone called "O:S-1-22-1-65534". That's a little weird, but
I'll accept it as an "alias" of Mr. nobody.
The Help for Set-Acl is a little worrying. I'm not entirely sure
how I'd work it but I *think* I would
"C:\PS>$DogACL = get-acl Z:\dog.txt" to store the NAS file's
security inside an ACLObject then
"C:\PS>set-acl -path C:\cat.txt -AclObject $DogACL" to copy a
valid, friendly security description from a file I *know* I own into
the ACLObject for the one I don't.
But that would mean doing them one file at a time, so I *think*
"C:\PS>$newACL = get-acl file0.txt" from a file I *know* I own,
then
"C:\PS>get-childitem Z:\Folder -recurse -include *.* -force |
set-acl -aclobject $newacl" to set the contents of the NAS folder to
be owned by me.
But I've never used PS so I don't know what, if anything, the
drastic repercussions would be. Some gentle hand-holding would be very
much appreciated, thanks.
If it matters, it's a Seagate and I've deleted other stuff from it.
Any aid and comfort would be appreciated. :)

Yes, Nobody is a UID up near the end of the numeric space.
You are doing an operation against the file system on the NAS.
It is the NAS file-system-property that is causing the problem.
I doubt any amount of Powershell spell casting is going to work.
It's not the ACL that needs changing, it's the Owner of the file.
In these two examples, you can see some of the suggestions are quite different.
The first one (for some sort of container), is ridiculous.
https://unix.stackexchange.com/questions/563942/debian-change-owner-of-nobodynogroup
Something like chown (change owner) would be a start. Sudo gives you
root (administrator) permissions. On Windows, the equivalent would
be using an administrator terminal, and just doing the chown.
sudo chown 1000:1000 some.file # 500 is root, 1000 is the beginning of users
# This is similar on windows and linux.
Also, note the comment at the end of this thread, regarding smb.conf on Linux.
It's an attempt to prevent the use of nobody for a Guest operation.
(Mapping Windows Guest [a low-privilege account] to Unix/Linux Nobody)
https://forums.linuxmint.com/viewtopic.php?t=238139
smb.conf
guest account = {bullwinkle} # Many of my Linux installs use "bullwinkle" as the user.
# chown bullwinkle:bullwinkle some.file would be my command
But this might be done from the shell of the NAS box. The chown command.
Just mapping the Guest account to bullwinkle after the fact,
likely won't "fix" the inaccessiblity of a Nobody problem.
The NAS box won't know who bullwinkle is, but if you know
the UID of bullwinkle, then this form should always be accepted
(and will do something, as long as the number used is a useful value).
The NAS box will use simple numbers from 0..65535 .
chown 1001:1001 some.file
On Linux, a typical convenience, is to make the uid and gid the
same value, as in "USER bullwinkle : GROUP bullwinkle". Whereas
in the real world, they could be anything, such as bullwinkle:chessclub.
The group does not have to be the same, but by default and for the
convenience of new users, they are made similar to be "less scary".
On Unix we wouldn't do it that way, ever. The "group" on Unix,
always represented an organizational group and wasn't purely arbitrary.
For example, my Linux account frequently belongs to "vboxusers" group,
as part of using VirtualBox. And it belongs to "sambausers" group
for doing certain file sharing things. Making the group be "bullwinkle"
does not confer any special magical powers, which is likely why they're
doing it that way.
To get some info about your Windows account, try this in Administrator window.
The last cluster of digits on the end, is like a UID. The three larger
clusters (in a non-Domain setup) belong to the OS installation and are
randomly assigned. That's why "Paul" on computer #1 is not the same
as "Paul" on computer #2. Only when you're in a Domain, with a Domain
server to manage things, are you always authenticating against the
Domain and the string of digits should be the same as you move from
one Domain machine to another.
wmic useraccount get name,sid

Hmm. Thank you.

Post by Paul
So the problem, may have come from the mapping of Windows Guest,
to Linux Nobody, and on some computing device, you need to "Change Owner"
of the file, to try to fix it. And it might require the shell on the
NAS box, as I don't really know if you can wrangle this from Powershell.
If Powershell cannot be convinced to do something to a Guest item,
then you'd have to switch over to the controls on the NAS box
and try from that namespace.
Paul

Okay.

Right.

Well.

Sir, you have done an enormous amount of effort for me and I deeply,
deeply thank you for it.

However: the suggested solutions are contingent on me finding a
Unixxy disk that I can still run, which might be possible but is too
much like work for today.

I do have *Nixxy disks somewhere and I'm fairly sure I can boot into
them without tampering with the Win-7 setup, run the OS from the CD or
something, but that's a "manyana" task. :)

I'm going to keep this post locked and highlighted.

Thank you.

J.





P.S.: I actually read and understood your help. I'm apparently not
entirely senile. ............ Yet. :)

[John]

On Mon, 17 Jul 2023 18:39:02 +0100, John <***@the.keyboard> wrote:

<<snipped>>

Post by John
I do have *Nixxy disks somewhere and I'm fairly sure I can boot into
them without tampering with the Win-7 setup, run the OS from the CD or
something, but that's a "manyana" task. :)

<<snipped>>

Okay, so I didn't need an OS on a disk because I've already got one,
on my MacBook Pro.

I fiddled about with chown and chmod in a Terminal on the MBP.

According to the exit codes [none] the chowns and chmods worked fine
and "File Info" tells me that I'm the new owner.

However: the damned things still have permission issues. I still
can't delete them. :)

MacOS *says* the owner has changed, Windows disagrees. Me, I'm
agreeing with Windows {now, there's a strangeness :)} because nothing
I have done lets me kill the files.

I've given up.

At some point, I'll find out how to format the disk.

Thank you for your help. Your post is in my "this is damned useful
stuff" archive.

J.

[Paul]

Post by John
<<snipped>>

Post by John
I do have *Nixxy disks somewhere and I'm fairly sure I can boot into
them without tampering with the Win-7 setup, run the OS from the CD or
something, but that's a "manyana" task. :)

<<snipped>>
Okay, so I didn't need an OS on a disk because I've already got one,
on my MacBook Pro.
I fiddled about with chown and chmod in a Terminal on the MBP.
According to the exit codes [none] the chowns and chmods worked fine
and "File Info" tells me that I'm the new owner.
However: the damned things still have permission issues. I still
can't delete them. :)
MacOS *says* the owner has changed, Windows disagrees. Me, I'm
agreeing with Windows {now, there's a strangeness :)} because nothing
I have done lets me kill the files.
I've given up.
At some point, I'll find out how to format the disk.
Thank you for your help. Your post is in my "this is damned useful
stuff" archive.

Would this be a problem with the parent directory ?

The one above the file ?

Also, it's possible when a remote thing connects to a share,
it connects as Guest and the effective account coming in is nobody:nogroup.

Perhaps Guest access needs to be disabled, so only devices with
account credentials can connect.

There's got to be a story in there somewhere, involving ownership
and emulated rights (what the presentation of credentials
gives the visitor as an identity).

Paul

[John]

Post by Paul

Post by John
<<snipped>>

Post by John
I do have *Nixxy disks somewhere and I'm fairly sure I can boot into
them without tampering with the Win-7 setup, run the OS from the CD or
something, but that's a "manyana" task. :)

<<snipped>>
Okay, so I didn't need an OS on a disk because I've already got one,
on my MacBook Pro.
I fiddled about with chown and chmod in a Terminal on the MBP.
According to the exit codes [none] the chowns and chmods worked fine
and "File Info" tells me that I'm the new owner.
However: the damned things still have permission issues. I still
can't delete them. :)
MacOS *says* the owner has changed, Windows disagrees. Me, I'm
agreeing with Windows {now, there's a strangeness :)} because nothing
I have done lets me kill the files.
I've given up.
At some point, I'll find out how to format the disk.
Thank you for your help. Your post is in my "this is damned useful
stuff" archive.

Would this be a problem with the parent directory ?

An inheritance issue? Hmmm ...

Post by Paul
The one above the file ?

Yes, yes, I *know* which one you're referring to ...

Oh ... YOU BEAUTY!

That was *so* damned *simple*!

THANK YOU!

I clicked on the containing directory/folder, opened up Properties,
clicked on Security, changed the permissions on Everyone to "Full
Control", which ticked all of the boxes below it and it allowed me to
delete a file. It then allowed me to delete *all* the files and the
container directory.

This was all done in Win-7, using Powerdesk-9, my replacement for the
file manager that comes with Windows.

Yes!

Thank you.

So, why the hell didn't *I* think of that? :)

Post by Paul
Also, it's possible when a remote thing connects to a share,
it connects as Guest and the effective account coming in is nobody:nogroup.

Yerp, maybe, but I no longer *care*! Or at least not as much as I
did. An itch in my wetware's operating subsystems has gone.

Post by Paul
Perhaps Guest access needs to be disabled, so only devices with
account credentials can connect.

There's no obvious way to do this on this drive but I'll poke about
to see if I can find one to prevent future incidents of a similar
nature.

TYhank you for the suggestion.

Ok, so, after "poking about", there is no Guest account. I can access
the drive on the account I set up in 2015 but that's an Administrator
account and the only one present. I *could* delete this but then I'd
have to do another set-up and I don't think Seagate allows this any
longer.

Post by Paul
There's got to be a story in there somewhere,

Yeah. The story is Me. Doing a stupid. Somehow. What stupid I did, I
have no idea but you are possibly right and it possibly involved a
nameless "Guest" account somehow.

Hey, it was 2015, lots of things have happened since then. I've
slept, had a meal, went into Town and fiddled about on several boxes.

It's been a busy five hundred years, including 2020. 2020 lasted at
least 493 of them.

Post by Paul
involving ownership
and emulated rights (what the presentation of credentials
gives the visitor as an identity).

No doubt.

But you solved it, so I'm ever so happy and ever so grateful.

Thank you.

J.

Post by Paul
Paul