Transferring Play on Linux files
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Transferring Play on Linux files
Hi:
Well, I thought this would be easy; just follow Cosmo's instructions as I did for Thunderbird:
viewtopic.php?f=47&t=268027
And away you go...well, not so fast, sonny boy... When I went to compress the files, I kept getting those annoying "permission denied" errors; no problem...switch to root and that will fix it... no, that will not fix it. At least I can use "apply permissions to enclosed folders".... Nope, still the same error. I could change them individually, but there are so many it would take 30 years.
Does anyone have a solution?
Thanks
Well, I thought this would be easy; just follow Cosmo's instructions as I did for Thunderbird:
viewtopic.php?f=47&t=268027
And away you go...well, not so fast, sonny boy... When I went to compress the files, I kept getting those annoying "permission denied" errors; no problem...switch to root and that will fix it... no, that will not fix it. At least I can use "apply permissions to enclosed folders".... Nope, still the same error. I could change them individually, but there are so many it would take 30 years.
Does anyone have a solution?
Thanks
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: Transferring Play on Linux files
I noticed your report in the TB thread already. It seems, we should take a look into your home to find out, if there are ownership problems.
Mark the following command and press ctrl-c
open a terminal and press ctrl-shift-V
Mark the complete result inclusive the command with the mouse and press ctrl-shift-C
In the forum click the Code-button (looks like
Report in case, that there is no output.
Besides that: "Switching to root" is not a solution for such problems, it merely can create new problems, which were not there until this attempt. As a general rule: Never(!) use inside of your home elevated rights!. If this seems(!!!) to be needed, it is an indication for a problem, which needs to get fixed. This brings me back to the above advice.
Mark the following command and press ctrl-c
Code: Select all
find $HOME ! -user $USER -type f
Mark the complete result inclusive the command with the mouse and press ctrl-shift-C
In the forum click the Code-button (looks like
</>
) above the text edit box, than press ctrl-v.Report in case, that there is no output.
Besides that: "Switching to root" is not a solution for such problems, it merely can create new problems, which were not there until this attempt. As a general rule: Never(!) use inside of your home elevated rights!. If this seems(!!!) to be needed, it is an indication for a problem, which needs to get fixed. This brings me back to the above advice.
Re: Transferring Play on Linux files
Cosmo:
I have one little problem, in that I am using the "from" drive as dev/sdb, with the "new", larger drive as dev/sda. Reason: I wanted to have an easier drive to drive transfer, and most importantly, that source drive rarely boots. I have tried many combinations of "mount", mount -l ext4 /dev/sdb2 (and 5) /mnt/DATA, mount device... etc., and it is all a no-go.
So.. I can't execute the terminal commands you gave me because I can't navigate to the drive at the command line. If it is worth anything, I can access it in the GUI, is there a way to obtain a terminal window from where the GUI is at?
Meanwhile, I will try to trick the drive into booting to try your commands.
Thanks.
I have one little problem, in that I am using the "from" drive as dev/sdb, with the "new", larger drive as dev/sda. Reason: I wanted to have an easier drive to drive transfer, and most importantly, that source drive rarely boots. I have tried many combinations of "mount", mount -l ext4 /dev/sdb2 (and 5) /mnt/DATA, mount device... etc., and it is all a no-go.
So.. I can't execute the terminal commands you gave me because I can't navigate to the drive at the command line. If it is worth anything, I can access it in the GUI, is there a way to obtain a terminal window from where the GUI is at?
Meanwhile, I will try to trick the drive into booting to try your commands.
Thanks.
Re: Transferring Play on Linux files
The given command investigates your home. Where your home is stored, does not matter at least. Just do as advised.
Re: Transferring Play on Linux files
Cosmo: Here are the results:
Thanks.
Code: Select all
x@2 ~ $ find $HOME ! -user $USER -type f
/home/x/Documents/Computer Technical/Funderbird.savedSearch
/home/x/software_selection_x-OptiPlex-GX270@2018-04-20-1203-package.list
Thanks.
Re: Transferring Play on Linux files
The output does not show anything related to your problem, but correct the wrong ownership anyway:
Mark the following command completely and make sure, that you do not miss any sign, than press ctrl-c
Open a terminal and enter
and press the Enter-key; you get prompted for your password, enter it.
Now still in the same terminal press ctrl-shift-V
Run this command and wait until it has finished. It does not produce a readable output.
Press twice ctrl-d
Immediately log off and back into your account.
What we now need is the precise error message, permission denied for what, when you try to compress?
Mark the following command completely and make sure, that you do not miss any sign, than press ctrl-c
Code: Select all
find /home/$SUDO_USER ! -user $SUDO_USER -exec chown $SUDO_USER:$SUDO_USER '{}' \;
Code: Select all
sudo -i
Now still in the same terminal press ctrl-shift-V
Run this command and wait until it has finished. It does not produce a readable output.
Press twice ctrl-d
Immediately log off and back into your account.
What we now need is the precise error message, permission denied for what, when you try to compress?
Re: Transferring Play on Linux files
Cosmo:
I am still getting an error message: "Permission Denied". There is nothing further to click on. This occurs as I am starting to compress from the source drive, (dev/sdb). It would seem that the issue exists at the source. Also, Gparted reveals this for the new install:
It looks to me as if it were one big boot sector; I must be missing something.
Thanks
I am still getting an error message: "Permission Denied". There is nothing further to click on. This occurs as I am starting to compress from the source drive, (dev/sdb). It would seem that the issue exists at the source. Also, Gparted reveals this for the new install:
It looks to me as if it were one big boot sector; I must be missing something.
Thanks
Re: Transferring Play on Linux files
Your picture shows sda, I cannot see anything regarding sdb.
Re: Transferring Play on Linux files
Cosmo:
That's the new install drive, the "old" drive is sdb.
I started suspecting that part of the flakeyness of that machine might be memory related, and memtester agreed. After cleaning the contacts and a light coat of De-Ox-It, it then tested 100% on both memtester and memtest86+ (or what ever it's correct name is, it is the one on the Gparted Live disk). Yet after that the compression still stopped and said "Permission Denied" (even in root). Usually there is a "details" arrow you can click on, but not with this. Is there a log of that operation kept somewhere?
I did some spot checking and could find no ownership problems, but that is not really a definitive test since I would need to check literally thousands of files to be sure. So I decided on a direct copy approach, (in root, just to make sure) and it copied without a hitch, so at least I'm at the 50% mark, I'll see if POL likes it later.
Meanwhile, back at the ranch, I figured it would be best to nuke that new install, since the drive format configuration is so bizarre. Gparted won't let me set what will be a boot sector at anything less than 15 GB, I don't know why it is acting that way, all the other installs I've done came out right, dev/sdb stands at 243 MB for example, so any suggestions would be appreciated.
Thanks.
That's the new install drive, the "old" drive is sdb.
I started suspecting that part of the flakeyness of that machine might be memory related, and memtester agreed. After cleaning the contacts and a light coat of De-Ox-It, it then tested 100% on both memtester and memtest86+ (or what ever it's correct name is, it is the one on the Gparted Live disk). Yet after that the compression still stopped and said "Permission Denied" (even in root). Usually there is a "details" arrow you can click on, but not with this. Is there a log of that operation kept somewhere?
I did some spot checking and could find no ownership problems, but that is not really a definitive test since I would need to check literally thousands of files to be sure. So I decided on a direct copy approach, (in root, just to make sure) and it copied without a hitch, so at least I'm at the 50% mark, I'll see if POL likes it later.
Meanwhile, back at the ranch, I figured it would be best to nuke that new install, since the drive format configuration is so bizarre. Gparted won't let me set what will be a boot sector at anything less than 15 GB, I don't know why it is acting that way, all the other installs I've done came out right, dev/sdb stands at 243 MB for example, so any suggestions would be appreciated.
Thanks.
Re: Transferring Play on Linux files
You wrote in your second last post, that sdb is the source drive. At first this is impossible, as the source must be in every case a partition, so e. g. sdb1. next you wrote, that you suspect the issue at the source. Then you wrote, that GParted reveals this and presented a picture of sda. This cannot help to see anything related.
Re: Transferring Play on Linux files
Cosmo:
Perhaps I haven't been completely clear.
(D)ev/sda and dev/sdb are two wholly separate drives, not different partitions on the same drive. (D)ev/sda, configured as the master, is the 160GB drive I wish to use for a new install, transferring files from dev/sdb, 40GB, my original drive, now configured as slave.
When I tried the compression technique, the process "error-ed out" in very short order, leading me to suspect that the routine was having trouble reading from dev/sdb, whereas if it had stopped much later in the process, I would suspect that it would be having trouble writing to dev/sda.
By way of reiteration: the compression failed with .PlayOnLinux, but not .thunderbird.
My confusion with dev/sda vis-a-vis Gparted is that there does not seem to be a separate boot partition, rather one big main partition and a small swap partition. I have never seen an install do this before. What I believe it should look like, (correct me if I have this wrong) would be something like 300MB as a boot partition (dev/sda1) 155GB for the "extended" area, (dev/sda2) and a swap area, let's say 4.7GB.
At any rate, even with the memory fixed, that computer still freezes up, although at a much longer interval.
Thanks.
Perhaps I haven't been completely clear.
(D)ev/sda and dev/sdb are two wholly separate drives, not different partitions on the same drive. (D)ev/sda, configured as the master, is the 160GB drive I wish to use for a new install, transferring files from dev/sdb, 40GB, my original drive, now configured as slave.
When I tried the compression technique, the process "error-ed out" in very short order, leading me to suspect that the routine was having trouble reading from dev/sdb, whereas if it had stopped much later in the process, I would suspect that it would be having trouble writing to dev/sda.
By way of reiteration: the compression failed with .PlayOnLinux, but not .thunderbird.
My confusion with dev/sda vis-a-vis Gparted is that there does not seem to be a separate boot partition, rather one big main partition and a small swap partition. I have never seen an install do this before. What I believe it should look like, (correct me if I have this wrong) would be something like 300MB as a boot partition (dev/sda1) 155GB for the "extended" area, (dev/sda2) and a swap area, let's say 4.7GB.
At any rate, even with the memory fixed, that computer still freezes up, although at a much longer interval.
Thanks.
Re: Transferring Play on Linux files
That was clear and could in no case be different. But drives themselves can never be the source (or the target) of any file operation. Only partitions can be. You see in your picture, that you have 2 partitions on sda, namely sda1 and sda5. (sda2 is a container for so called logical drives.) Also on sdb there must exist partitions, otherwise no file manager or any other application could access it. But nobody can know more without seeing your sdb.
Re: Transferring Play on Linux files
Cosmo:
And here it is: Thanks.
And here it is: Thanks.
Re: Transferring Play on Linux files
The main partition on sdb, sdb5, seems to be encrypted. I don't use this and have never dealt with this. So I am out.
Re: Transferring Play on Linux files
Cosmo:
I would never encrypt..that is really asking for trouble...since I did NOT encrypt, what makes it appear to be so?
I would never encrypt..that is really asking for trouble...since I did NOT encrypt, what makes it appear to be so?
Re: Transferring Play on Linux files
The lvm file system for sdb5.
Re: Transferring Play on Linux files
Cosmo: You mean to say that Logical Volume Management is/a form of encryption?
Re: Transferring Play on Linux files
LVM can serve several purposes, but encrypting is likely the mostly used reason to use LVM. At least you should know, if and why you created this lvm partition; If not I can only assume you did it by error.
Re: Transferring Play on Linux files
Cosmo:
This is an old, used drive I got from somewhere some years ago, which I installed over. It might be a carry over, or maybe I decided to try LVM.
Now I know why not to check that "use Logical Volume Management" question on in install disks, and you can bet that I won't!
Another mistake made, but another lesson learned.
Thanks
This is an old, used drive I got from somewhere some years ago, which I installed over. It might be a carry over, or maybe I decided to try LVM.
Now I know why not to check that "use Logical Volume Management" question on in install disks, and you can bet that I won't!
Another mistake made, but another lesson learned.
Thanks