Having dutifully followed advice and backed up my NAS drive using rsync, I have formatted the NAS and now want to write the contents of the rynced drive back to the NAS. But it gives me lots of 'Permission Denied' errors. I thought I'd re-created the NAS as it was but that's done through a web browser so I might well have screwed it up but it seems to be working, albeit that I can't now write to it.
So once and for all, I'd like to fix the problem so that in the future, I can read and write files to the NAS without experiencing permission errors.
I tried to find the cause of this error on google but it only returns one result and that's no help at all. I then looked at the groups configuration GUI on the machine but there are no groups numbered above 500 so how come this one is saying 199528447? If it helps, the user number is the same.
So where do I start with trying to fault find this?
On 4 March 2013 16:53, Chris Walker cdw_alug@the-walker-household.co.uk wrote:
Having dutifully followed advice and backed up my NAS drive using rsync, I have formatted the NAS and now want to write the contents of the rynced drive back to the NAS. But it gives me lots of 'Permission Denied' errors.
I'm unclear where you're seeing the GID of 199528447 appear, is it in this error message?
I tried to find the cause of this error on google but it only returns one result and that's no help at all. I then looked at the groups configuration GUI on the machine but there are no groups numbered above 500 so how come this one is saying 199528447? If it helps, the user number is the same.
Without knowing where this GID (and matching UID) is appearing I'm a bit stuck.
AIUI[*], when you rsync from host A to host B, if the same user/group appears on both systems then ownership should be retained even though the user/group ID (provided you told rsync to retain owner information, which is implied by -a, although something that didn't get mentioned in previous conversations is that rsync can only retain owner information if run as root). This begs the question of what happens if the user on host A doesn't exist on host B - I believe that in that case the numeric ID is retained.
If I start with the following users: <Host A> 1000,user1 1001,user2 1002,user3 1010,userA <Host B> 1000,user1 1002,user2 (same user but different UID) 1003,user3 (ditto) 1004,user4 (user unique to Host B)
.. and rsync from HostA to HostB, files initially owned by user1,user2,user3,and userA on HostA will now be owned on HostB by user1(easy),user2(matched on username),user2(matched on user ID),and non-existent user 1010 respectively. If that process created the backup, then you can apply the same logic to work out where the files end up on HostC.
Hopefully somewhere in all that will be an explanation that matches your symptoms? All comments about user(owner)/uid apply equally to group/gid.
[*]AIUI = As I Understand It. I'm not an rsync guru and this is what I believe through experience, which I just double checked in the rsync man pages to be more confident but I may well have missed something. Corrections welcome!
On 05/03/13 06:16, Mark Rogers wrote:
On 4 March 2013 16:53, Chris Walker cdw_alug@the-walker-household.co.uk wrote:
Having dutifully followed advice and backed up my NAS drive using rsync, I have formatted the NAS and now want to write the contents of the rynced drive back to the NAS. But it gives me lots of 'Permission Denied' errors.
I'm unclear where you're seeing the GID of 199528447 appear, is it in this error message?
Nope. Having seen the message on the console, using the file manager I then right click on the folder into which I am trying to write. I then look at Permissions and it is there that the user/group are displayed.
AIUI[*], when you rsync from host A to host B, if the same user/group appears on both systems then ownership should be retained even though the user/group ID (provided you told rsync to retain owner information, which is implied by -a, although something that didn't get mentioned in previous conversations is that rsync can only retain owner information if run as root). This begs the question of what happens if the user on host A doesn't exist on host B - I believe that in that case the numeric ID is retained.
Ok. So if I then list, for example, the directory shown below on the Seagate drive, it gives me this (just a couple of files shown) :-
ls -l /media/Seagate\ Backup\ Plus\ Drive/Epox_Share/Drive_C/Library/ total 12465 -rw------- 1 chris cdrom 936885 Feb 28 16:08 5_Fonts.zip -rw------- 1 chris cdrom 23552 Feb 28 16:08 aefdisk.zip
But using this command :- rsync -r /media/Seagate\ Backup\ Plus\ Drive/Epox_Share/Drive_C/Library /media/Epox_Share/Drive_C/
I get this :- rsync: recv_generator: mkdir "/media/Epox_Share/Drive_C/Library" failed: Permission denied (13) *** Skipping any contents from this failed directory ***
[snip]
Hopefully somewhere in all that will be an explanation that matches your symptoms? All comments about user(owner)/uid apply equally to group/gid.
I'm afraid I don't understand that. Following an explanation on here some time ago, I thought I had begun to get a grip on groups etc but plainly I didn't!
But dredging the memory banks, if I type 'groups' I get this :- cdrom wheel usb cdwriter users vboxusers
So looking at what groups are shown for the Seagate Library folder, it seems I *am* a member of the cdrom group so why can't I write the files/create directories etc on the NAS?
On Tue, Mar 05, 2013 at 10:37:54AM +0000, Chris Walker wrote: [snip]
Ok. So if I then list, for example, the directory shown below on the Seagate drive, it gives me this (just a couple of files shown) :-
ls -l /media/Seagate\ Backup\ Plus\ Drive/Epox_Share/Drive_C/Library/ total 12465 -rw------- 1 chris cdrom 936885 Feb 28 16:08 5_Fonts.zip -rw------- 1 chris cdrom 23552 Feb 28 16:08 aefdisk.zip
[snip]
But dredging the memory banks, if I type 'groups' I get this :- cdrom wheel usb cdwriter users vboxusers
So looking at what groups are shown for the Seagate Library folder, it seems I *am* a member of the cdrom group so why can't I write the files/create directories etc on the NAS?
Simple, because they haven't got the group write (or any other) permission set.
In the -rw------- flags you see before the file names the first - indicates various odd flags, then there are three groups of three which can be set to r, w, and x for read, write and execute permission respectively. The first three are for Owner, the next three are for Group and the last three are for Anyone/world. So on the above files you have only Read and Write permission for the owner. The files have group cdrom but no permissions for that group.
On 05/03/13 11:57, Chris Green wrote:
On Tue, Mar 05, 2013 at 10:37:54AM +0000, Chris Walker wrote: [snip]
Ok. So if I then list, for example, the directory shown below on the Seagate drive, it gives me this (just a couple of files shown) :-
ls -l /media/Seagate\ Backup\ Plus\ Drive/Epox_Share/Drive_C/Library/ total 12465 -rw------- 1 chris cdrom 936885 Feb 28 16:08 5_Fonts.zip -rw------- 1 chris cdrom 23552 Feb 28 16:08 aefdisk.zip
[snip]
Simple, because they haven't got the group write (or any other) permission set.
In the -rw------- flags you see before the file names the first - indicates various odd flags, then there are three groups of three which can be set to r, w, and x for read, write and execute permission respectively. The first three are for Owner, the next three are for Group and the last three are for Anyone/world. So on the above files you have only Read and Write permission for the owner. The files have group cdrom but no permissions for that group.
Ah.
So if I try and reset the permissions on those files by using chmod 777 5_Fonts.zip, nothing happens. I've tried it using my userid and also using sudo but with the same result. Where am I going wrong? Do I need to set permissions on all the parent folders for that file too?
The next question occurs to me though, how did I manage to screw this up as I imagine that the files on the NAS weren't like this before I copied them. So was it my incorrect use of the rsync command? If so, then I guess I'm likely to have similar problems when the files are back on the NAS.
On Tue, Mar 05, 2013 at 12:04:58PM +0000, Chris Walker wrote:
On 05/03/13 11:57, Chris Green wrote:
On Tue, Mar 05, 2013 at 10:37:54AM +0000, Chris Walker wrote: [snip]
Ok. So if I then list, for example, the directory shown below on the Seagate drive, it gives me this (just a couple of files shown) :-
ls -l /media/Seagate\ Backup\ Plus\ Drive/Epox_Share/Drive_C/Library/ total 12465 -rw------- 1 chris cdrom 936885 Feb 28 16:08 5_Fonts.zip -rw------- 1 chris cdrom 23552 Feb 28 16:08 aefdisk.zip
[snip]
Simple, because they haven't got the group write (or any other) permission set.
In the -rw------- flags you see before the file names the first - indicates various odd flags, then there are three groups of three which can be set to r, w, and x for read, write and execute permission respectively. The first three are for Owner, the next three are for Group and the last three are for Anyone/world. So on the above files you have only Read and Write permission for the owner. The files have group cdrom but no permissions for that group.
Ah.
So if I try and reset the permissions on those files by using chmod 777 5_Fonts.zip, nothing happens. I've tried it using my userid and also using sudo but with the same result. Where am I going wrong? Do I need to set permissions on all the parent folders for that file too?
Can you show us what exactly happens please. Is there any error message or what? Do you cd to the directory and then run the chmod or are you doing something like:-
chmod 777 /media/Seagate\ Backup\ Plus\ Drive/Epox_Share/Drive_C/Library/
... the other possibility is that there's something in the way the files are mounted that's preventing you from changing their permissions (and, similarly, preventing you from writing them). If you type 'mount' what does it report?
The next question occurs to me though, how did I manage to screw this up as I imagine that the files on the NAS weren't like this before I copied them. So was it my incorrect use of the rsync command? If so, then I guess I'm likely to have similar problems when the files are back on the NAS.
The files listed above *are* on the NAS aren't they? It looks like it from the directory path - or am I very confused (quite likely)?
On 05/03/13 12:13, Chris Green wrote:
Can you show us what exactly happens please. Is there any error message or what? Do you cd to the directory and then run the chmod or are you doing something like:-
I'm cd'ing to the directory you've listed below and then trying to run the chmod command. There are no errors
chmod 777 /media/Seagate\ Backup\ Plus\ Drive/Epox_Share/Drive_C/Library/... the other possibility is that there's something in the way the files are mounted that's preventing you from changing their permissions (and, similarly, preventing you from writing them). If you type 'mount' what does it report?
/dev/sda2 on /media/win_c type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions) /dev/sdb6 on /home type ext4 (rw,commit=0) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) //storage_server/Laptop_Share on /media/Laptop_Share type cifs (rw,noexec,nosuid,nodev) //storage_server/Epox_Share on /media/Epox_Share type cifs (rw,noexec,nosuid,nodev) //storage_server/Linux_Share on /media/Linux_Share type cifs (rw,noexec,nosuid,nodev) //storage_server/Media_Share on /media/Media_Share type cifs (rw,noexec,nosuid,nodev) /dev/sdc1 on /media/Seagate Backup Plus Drive type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions) gvfs-fuse-daemon on /home/chris/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=chris)
For completeness, here is the output from ls -l
drwxrwxrwx 3 root root 0 Jan 1 1970 Epox_Share/ drwxrwxrwx 2 root root 0 Mar 4 12:40 Laptop_Share/ drwxrwxrwx 2 root root 0 Mar 4 12:40 Linux_Share/ drwxrwxrwx 2 root root 0 Mar 4 15:58 Media_Share/ drwx------ 1 chris cdrom 16384 Mar 4 16:15 Seagate Backup Plus Drive/ drwxrwxrwx 1 root root 28672 Feb 28 11:10 win_c/
The next question occurs to me though, how did I manage to screw this up as I imagine that the files on the NAS weren't like this before I copied them. So was it my incorrect use of the rsync command? If so, then I guess I'm likely to have similar problems when the files are back on the NAS.
The files listed above *are* on the NAS aren't they? It looks like it from the directory path - or am I very confused (quite likely)?
The NAS is 'storage_server' and the drive I copied 'to' from the NAS originally is the 'Seagate Backup' drive. I'm now seeking to transfer the contents of 'Seagate Backup' back to 'storage_server' and it's there I'm running into problems.
On Tue, Mar 05, 2013 at 12:26:14PM +0000, Chris Walker wrote:
On 05/03/13 12:13, Chris Green wrote:
Can you show us what exactly happens please. Is there any error message or what? Do you cd to the directory and then run the chmod or are you doing something like:-
I'm cd'ing to the directory you've listed below and then trying to run the chmod command. There are no errors
OK, my guess then is that it's something to do with the way the drive is mounted.
/dev/sdc1 on /media/Seagate Backup Plus Drive type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
This is the relevant one, that "type fuseblk" worries me slightly (mostly because I don't know what it means!). ... a quick google informs me that fuseblk indicates that it's probably a non-Linux drive formatted as ntfs or something similar.
For completeness, here is the output from ls -l
drwxrwxrwx 3 root root 0 Jan 1 1970 Epox_Share/ drwxrwxrwx 2 root root 0 Mar 4 12:40 Laptop_Share/ drwxrwxrwx 2 root root 0 Mar 4 12:40 Linux_Share/ drwxrwxrwx 2 root root 0 Mar 4 15:58 Media_Share/ drwx------ 1 chris cdrom 16384 Mar 4 16:15 Seagate Backup Plus Drive/ drwxrwxrwx 1 root root 28672 Feb 28 11:10 win_c/
The next question occurs to me though, how did I manage to screw this up as I imagine that the files on the NAS weren't like this before I copied them. So was it my incorrect use of the rsync command? If so, then I guess I'm likely to have similar problems when the files are back on the NAS.
The files listed above *are* on the NAS aren't they? It looks like it from the directory path - or am I very confused (quite likely)?
The NAS is 'storage_server' and the drive I copied 'to' from the NAS originally is the 'Seagate Backup' drive. I'm now seeking to transfer the contents of 'Seagate Backup' back to 'storage_server' and it's there I'm running into problems.
I think the problem is the Seagate Backup drive. It appears not to have a Linux filesystem on it and the permission flags don't map to or from it properly. So you *can't* get the right permissions on the files if you copy them to/from that drive.
On 05/03/13 12:52, Chris Green wrote:
OK, my guess then is that it's something to do with the way the drive is mounted.
/dev/sdc1 on /media/Seagate Backup Plus Drive type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
This is the relevant one, that "type fuseblk" worries me slightly (mostly because I don't know what it means!). ... a quick google informs me that fuseblk indicates that it's probably a non-Linux drive formatted as ntfs or something similar.
[snip]
I think the problem is the Seagate Backup drive. It appears not to have a Linux filesystem on it and the permission flags don't map to or from it properly. So you *can't* get the right permissions on the files if you copy them to/from that drive.
Well spotted. I hadn't thought of that. I'll take more care in future. Lesson learnt. Ta.
On 04/03/13 16:53, Chris Walker wrote:
Having dutifully followed advice and backed up my NAS drive using rsync, I have formatted the NAS and now want to write the contents of the rsynced drive back to the NAS. But it gives me lots of 'Permission Denied' errors. I thought I'd re-created the NAS as it was but that's done through a web browser so I might well have screwed it up but it seems to be working, albeit that I can't now write to it.
So once and for all, I'd like to fix the problem so that in the future, I can read and write files to the NAS without experiencing permission errors.
For info, I have now managed to fix this error on the NAS.
As usual, it was an ID10T error. I didn't have any user or group setting specified in the fstab file. I noticed when playing with my Raspberry Pi that when I wrote to the NAS, it came up with some different numbers. That prompted me to look into fstab settings. I can now write to the NAS and the files are now set like this :- -rwxrwxrwx 1 chris users 744484 Jan 23 12:31 IMG_00000005.jpg* where previously they would have had userid and group settings of 199528447.
-
Chris Green -
Chris Walker -
Mark Rogers