chown and why it doesn't work?

[Munty Scruntfundle]

Hi folks.

I have recently moved a data store from one server to another, different ips, different disks but same file system. I performed everything as root (same login details) on both machines.

However, now I can't edit the files. I can open, but no permission to save. This suggests there is a file somewhere that hasn't been copied? Is there a file that stores file permissions? I thought it was all encapsulated in the file headers, but I could be wrong.

Anyway, I have chown root /datastore/* which gives no errors, but still I can't edit the files.

So, one, I'm wondering why the permissions for root are now different to what they were, when as far as I can see I've synced everything correctly? And two, why won't chown, as root, for root, give me access.

Rather than just a - do this - kind of approach, could someone please explain why and what's happened here so I can learn from the experience?

Many thanks.

[wizard10000]

Hi, Munty -

Did you verify that permissions had actually changed? Also,

Code: Select all

chown root /datastore/*

will only change the permissions of files directly under /datastore; anything in subdirectories wouldn't have changed.

Does

Code: Select all

ls -la /datastore

show that permissions on files and directories has actually changed?

[p.H]

I have recently moved a data store from one server to another

How ?

However, now I can't edit the files. I can open, but no permission to save.

Can you show evidence ? (commands, error messages...)
How do you access the files ? Locally or remotely (NFS...) ?
You could create the files, so you should be able to edit them too.

Is there a file that stores file permissions? I thought it was all encapsulated in the file headers

Neither. File permissions are part of the filesystem metadata, not of the file contents.

why won't chown, as root, for root, give me access.

Root bypasses file permission checks on local files, so it does not need any permission. This is why I asked whether you access the files locally or remotely.

[GarryRicketson]

So, one, I'm wondering why the permissions for root are now different to what they were, when as far as I can see I've synced everything correctly?

What version of Debian is this ? I know based on your other posts you have said Buster, (testing) But you should tell us, in this thread, what version it is, we have no way of knowing if it is the same as what you were using, and also nobody should have to go looking through all your posts, to try to guess.

Rather than just a - do this - kind of approach, could someone please explain why and what's happened here so I can learn from the experience?

Ok, fair enough, I won't say do "this" or "that", but can not explain why, without seeing
exactly , what commands and how you wrote them, in code boxes, might give a clue to
what is going on. Include, showing exactly how you write the command to become root, also, exactly what commands, and syntax you used to sync,

as far as I can see I've synced everything correctly?

"Rather than just a - do this - kind of approach, ", ok again, I won't tell you what to do,
but a hint here, it all depends on what the attributes of the directory, and files, subdirectories , are. 'chown' does not change the attributes, if the attributes are set to read only, nobody, not even root can write to them (edit or delete content)
I am guessing wildly here, since you do not show anything to let us see how you synced the files, etc,... but my guess is somehow you managed to change the attributes, and now even root can not edit them.
Here is 2 links that might help you: https://www.linuxtechi.com/file-directo ... r-command/
and
https://wiki.archlinux.org/index.php/Fi ... attributes
Since you do not show us anything about these directories and files, it is all just guessing,
any way.
Ahh, and one last hint, if the attributes are set to read only, all though not even root can edit those files, if the admin that has logged in as root is qualified to be working as root, well they would know, as root you can change the attributes so that the files can be edited.
====edited===
Another thought, when I was feeding the birds, Bryan suggested this, how ever this:

I have recently moved a data store from one server to another, different ips, different disks but same file system.

Is not clear enough, What kind of data store ? Just saying "data" files, is to vague, but any way, Bryan suggested to me, he asked me if these were from a data base, are they ? A example , if it was a mysql, or mariadb, simply moving them, copying, and even rysync, is not good enough, and those kind of files are not writeable normally , if and when you copy or move a data base there is specific ways to do that, and it varies depending on the data base. Bryan says "Better details get better
answers."

[Munty Scruntfundle]

Hi folks.

Yes, data store was kind of vague. Just a bunch of directories with files in, sh files, py files, a couple of iso, nothing special, not databases.

Copying: cp. I think, but it was a while ago now, could have been synced.

Permissions: They look the same with an ls -l. On the original drive I can still create, edit, save etc the source. Same logon on the new node I can't edit the destination.

Login: I use ssh, they're all headless. On all nodes I use sudo su, I'm happy working that way.

I don't know what you want me to list in terms of output, nano says permission denied, rm returns permission denied, would a whole list of that help much? Permission example would be -rwxr-xr-x same on both drives. Scripts run ok as long as they don't alter any existing files on the data drive.

Files systems are ext4 on both satas and Debian is 9.9 Stretch.

The source is still available, I'm happy to clear the destination and copy everything again is you can suggest another way to do this and test what's going on?

Thanks again folks.

[p.H]

It is still unclear to me how you moved the data. Did you copy over the network or physically moved a disk ?

Can you post the output of the following commands ? (replace /path/to/some/file with the real pathname of an unvaluable text file)

Code: Select all

id
file=/path/to/some/file
stat $file
stat $(dirname $file) # (parent directory)
echo "append" >> $file
rm $file

Note : "sudo su" is absurd. Use either sudo or su, not both.

[Munty Scruntfundle]

Two drives. Two servers. Network copy, from a samba share.

Could you mount have anything to do with it, at copy or access time?

[p.H]

I doubt that ext4 (Unix-style) permissions and ownerships can be properly exported through samba (Windows-style).
Are you trying to modify files on a local or remote filesystem ? Even the local root account does not usually have root permissions on a remote filesystem.

[GarryRicketson]

Could you mount have anything to do with it, at copy or access time?

Yes, very much so, if it is mounted as read only, then it is read only, you can not edit any files, not even root can.
I was think about it could be something to do with how you are mounting the drive, can you show exactly the command you are using to mount it ?
Everything I am seeing here, sounds like a drive that is mounted read only,... Since you are not giving us any kind of details, nor showing the output of any thing that has been suggested, I don't understand why you are making it so hard for anyone to help ?
I said it before, but again, if you refuse simply do some of the things suggested, there is no way to say why it is happening.
Also, this :

Code: Select all

chown root /datastore/*

will only change the permissions of files directly under /datastore; anything in subdirectories wouldn't have changed.

Is not correct at all, read the manual on 'chown' , all it does is change owner of the files or directory, it does NOT change any permissions or attributes. If a drive is mounted read only, changing who owns the files on it, will not change the fact that it is mounted read only, or has read only attributes set.
chown works just fine for changing who owns the file, nothing more .
---
Show us the output as requested by P.H. also this:

Code: Select all

ls -la /datastore 

IF that is the correct path to this directory, and the files in it.
STOP with the vague statements:

Permissions: They look the same with an ls -l. On the original drive I can still create, edit, save etc the source. Same logon on the new node I can't edit the destination.

This does not tell us anything, you have not shown us what the output was with 'ls -l' on
Use code boxes and show the real output, not your vague descriptions of what it said.
For example:

Code: Select all

$ ls -a mailwrapper
-r-xr-xr-x  1 root  bin  9856 Oct 11  2018 mailwrapper

To make it easier, also show the path to the file:

Code: Select all

 garry$ pwd
/usr/sbin
garry$ ls -l mailwrapper
-r-xr-xr-x  1 root  bin  9856 Oct 11  2018 mailwrapper

===== more examples:
Note, I had to switch to being root, to do this.

Code: Select all

garry$ su 
Password:
garry# chown root  Loros-de-Mexico
garry# exit
garry$ ls -l Loros-de-Mexico
-rw-r--r--  1 root  garry  105 Jul 23  2018 Loros-de-Mexico
garry$  

The point is, note, the "-rw-r--r--", shows it is read write, changing the owner does not change the permissions / attributes. But this does:(below)

Code: Select all

garry$ su
Password:
garry# chmod -w Loros-de-Mexico
garry# exit
garry$ ls -l Loros-de-Mexico
-r--r--r--  1 root  garry  105 Jul 23  2018 Loros-de-Mexico
garry$  

Or you can use the 'chattr' command to do that. Note, now that I changed the attributes it is read only, nobody not even root can edit this file.
We need to see some real out put of the commands and output, that is the main point of my examples, use code boxes like I did, and copy/paste the out put into them

[Munty Scruntfundle]

I didn't get chance to get back to this until today.

I couldn't see any problems with the mounts, certainly not read only, I could create new files on the drive from anywhere, just couldn't edit a bunch of them.

I went back to the original data source just to check I wasn't going mad, but no, everything was normal and working ok there ON THAT node. As soon as the data moved to the new node the problems started. I have got around this for now, not ideal but a chmod 0+rwx on the source means I can now copy the source to the destination and it still be usable.

What I've realised is Root is not an identical user on the source and destination, although both ssh sessions are identical from the same machine with the same login and both are sudo su. I can replicate the problem in the opposite direction, both formats are the same, both mounts are the same, both samba setups are identical. Now, call me nuts, but I thought a user was a user regardless of where they log on.

So, under what circumstances would Root be considered unique on different nodes. One node is running Raspbian, one is running Full Debian Stretch, but surely root is still root?

Where is the data for user/file privileges? if 20 groups/users can open file A, but only 3 can open file B this has to be stored somewhere. Is it possible to interrogate?

Thanks again.

[Munty Scruntfundle]

Just to clarify a point, what I mean by Root not being the same user:
Root creates a file on node A. Root on node B can't edit the file, and the same In reverse. I've proved this to be true if the files stay in the created location or copied to a new location/node/disk.

[p.H]

You have constantly failed to provide the information and clarification I have requested repeatedly, so I'm out of this thread.

[GarryRicketson]

I am inclined to agree here, and the most recent post, way to long, but never even mentions how the OP gets root access,
But on last tip / hint:

Code: Select all

su -

is the better method of becoming root, or

Code: Select all

sudo -i

See the 'man su ' and 'man sudo' for details.

[Munty Scruntfundle]

Yes I did. I said all sessions are sudo su.

And yes I did, I gave you examples of the attributes.

You want me to copy and paste a session screen on one machine, save it to a usb, bring it to this machine and copy and paste it in here, which will show you exactly the same characters in the exactly the same places I've already mentioned.

And my last post proves the thread has moved on somewhat, most of the previous information given is pointless. Should I open another thread with the new information or will you slate me for that?

And my reply was too long? Now I get slated for giving too much information. Blimey, you can't win round here.

Thank you so much, I really appreciate your gracious help.

[GarryRicketson]

You are very welcome, it really is nice when people say thank you.

That is why you need to learn how to use code boxes, if you did post some where you used

Code: Select all

$ sudo su

It would be easy to see and read, using "sudu su" is absurd, and ridicules, I think I did see where some one else commented on that.

You want me to copy and paste a session screen on one machine, save it to a usb, bring it to this machine and copy and paste it in here, which will show you exactly the same characters in the exactly the same places I've already mentioned.

And my last post proves the thread has moved on somewhat, most of the previous information given is pointless. Should I open another thread with the new information or will you slate me for that?

NO, do not open another thread on the same topic. SEE:
Forum guidelines. Please read before first post!

1.Before you start using Debian User Forums, please observe the following guidelines:

Do not cross post. Posting the same topic in more than one category only creates confusion and makes it hard to keep track on the various replies. Double posts will be locked.---please- read the rest if you have not yet done so---

What you can or should do, actually 2 choices here, 1st this:

You want me to copy and paste a session screen on one machine, save it to a usb, bring it to this machine and copy and paste it in here, which will show you exactly the same characters in the exactly the same places I've already mentioned

Since we can not be there, to see exactly what is going on, so yes, basically that is what we need, but please be sure to use code boxes when you paste the output into your posts here.
If you do not understand how to use code boxes, there is some instruction here:
[url=http://forums.debian.net/viewtopic.php?f=16&t=123831]Attachments, How to post a screen shot and use code boxes[/code]
============
You can either edit your previous posts, use code boxes to show the details and output we have missed,
or, start fresh, with a new post, in this same thread, include the new details, etc, My thoughts it would be easiest for you to just put the new details , in you next post in this same thread, and start trying to be more clear about everything:

most of the previous information given is pointless. Should I open another thread with the new information

So in simple words, no, do not start a new thread, yes post the new information in your next reply.

[dilberts_left_nut]

Yes I did. I said all sessions are sudo su.

Which is meaningless

And yes I did, I gave you examples of the attributes.

which, in isolation and without relevant context, is next to useless as well

You want me to copy and paste a session screen on one machine, save it to a usb, bring it to this machine and copy and paste it in here, which will show you exactly the same characters in the exactly the same places I've already mentioned.

yes - verbatim input and output is required.
As the problem is clearly user error / misunderstanding of the mechanism's involved, your interpretation of what you think is happening doesn't help anyone here.

Thank you so much, I really appreciate your gracious help.

People want to help you, but you need to provide the info so they can.