Then do.
It’s what everyone not English native speaker does every day!
You never know where you may find useful info.
I translated a piece of it here above for you. Some other comments are already in English.
C’mon you have to do your part too 
I would say that reboot and then power button to put it off - shutdown option from start menu can be this hybrid hibernation by default, and reboot is always a full reboot.
After some testing here is what I got.
id -u $USER to get your user ID, probably 1001
id -g $USER to get your group ID, probably 1000
blkid to get the UUID for your external drive, but we will ignore the quotation marks when using this UUID. Mounting with /dev/sd* can cause problems because sometimes drives get enumerated in a different order, and will get assigned a different letter.
sudo nano /etc/fstab
Add a line for your ntfs drive, using the UUID and your preferred mount location:
UUID=abcd-1234-wxyz-5678 /mnt/ ntfs nofail,uid=1001,gid=1000,dmask=022,fmask=133 0 0
Reboot for voodoo reasons, and check your read/write access.
90% of the time when I try to use NTFS on Linux I run into that issue and usually the fix is to boot up windows(if dual boot, if not you gotta go find a windows PC to fix it) and run a repair on the drive because Linux corrupts the drives.
A work around for me is to format all drives that will be accessed by both Windows and Linux into exFAT. no more issues now.
So basically any external drives use exFAT.
I do the same thing for my internal Windows server, all the drives that I share files with from Linux are also formatted with exFAT.
1 Like
If fixing the disk with official Windows install does not remove problem, testing with local loopback file system might yield some insight. There are some cons with this, however. Although the commands used are not particularly dangerous, some command line skill is needed and the test is not necessarily conclusive.
Also, a correction! We had some behind-the-scenes testing with @WilsonPhillips and contrary to my belief, it turned out that both owner and group can indeed be arbitrarily changed on ntfs! How it manages that, is still beyond me, but chown -r should still be regarded as being possibly needed.
1 Like
Not -r.
We only want to change the owner of the drive. The files are all in an NTFS partition and we don’t need to touch them. We need some info first.
I need to see the output from
id
Then, with the drive plugged in.
lsblk -ao path,label,uuid,fstype
So so sorry for taking 10 billion years to get back when it should have been a couple days. I got extremely busy for a few weeks and than had a mini heat wave I had to deal with and I don’t cope well in the heat. I apologise if this has thrown anyone off with remembering what this topic is all about, I have to read through the topic again to catch myself up. I will also translate and read through the other topic @rugyada as you suggested. I’ve finally managed to find some time to get back to this.
Yes, it has been a while. Good to see you back!
Lets see the output of
id
and then
lsblk -ao path,label,uuid,fstype
@WilsonPhillips Sigh. Unfortunately my OpenMandriva install has broken out of nowhere. I appear to be having the same issue as the guy in this post OM doesn't boot after latest update.
So, now I’m unable to fix the hard drive issue because OpenMandriva won’t boot after updating it a couple of days ago. And no, unlike the person in that post, I did not use Discover because I learned the dangers of that with my thread here. I used the official software update tool provided in the app menu.
I’m making this post from a live mode USB.
I also made a discovery that should help with this hard drive issue, after doing some testing:
A month ago when I initially made this post, I tested my hard drive on my Windows 10 laptop and found that it works. What I somehow forgot, was that I have another, older laptop, which I put PeppermintOS on sometime last year. So, just yesterday I tested to see if the Hard Drive worked fine on that, and what do you know, it does!
So I decided to try it on some other Linux installs. I tested multiple live USB’s on my desktop to see if it mounted fine and if the error was just a part of my speciffic OM install. First, I tried a live version of the same version as I already have installed - ROME Plasma6.wayland AMD CPU (newer than 2017) - and tested the hard drive on it. It turns out, on the live USB, I still get the same error as what this whole post is about. This appears to indicate that there is something wrong with OpenMandriva ROME when running on my particular hardware. So it might be something that the developers need to fix.
I know it’s not a problem with my computer alone, because I then went ahead and tested a live USB of Linux Mint 22.1 Cinnamon Edition and the hard drive mounted just fine.
I also tested the non-wayland version of OpenMandriva ROME (specifically ROME Plasma6 AMD CPU (newer than 2017) and I still get the same mount error.
I also tried the non-wayland and non-AMD version ROME Plasma6 x86_64 and that also has an error when mounting.
In summary, these were the distros and versions I tested:
Fully Installed on desktop:
ROME Plasma6.wayland AMD CPU (newer than 2017) - Error mounting HDD
Live USB on desktop:
ROME Plasma6.wayland AMD CPU (newer than 2017) - Error mounting HDD
ROME Plasma6 AMD CPU (newer than 2017) - Error mounting HDD
ROME Plasma6 x86_64 - Error Mounting HDD
Linux Mint 22.1 Cinnamon Edition - Successfully mounts (plus all permissions)
Fully installed on laptop:
Some version of PeppermintOS (didn’t check) - Successfully mounts (plus all permissions)
I’m currently flashing OpenMandriva ROCK onto my USB and I’m going to test that out in live mode too. Because to be honest, if this is a problem with ROME that can be fixed in an update, I might just stick with ROCK for the time being until the problem is fixed. Otherwise if ROCK doesn’t fix the issue, I’ll have to temporarily use another Linux distro entirely for the time being, which would be disappointing because I’ve been really enjoying OpenMandriva outside of this one major issue (oh, and the latest update bricking the install of course)
Update: I have installed OpenMandrivaLx.5.0-slim-plasma.x86_64.iso to my USB and in live mode the error still occurs.
One more time, I need the output from these commands.
id
and
lsblk -ao path,label,uuid,fstype
But how can I do that command? I can’t boot into the OS because a recent update appears to have broken the system.
Make a new thread or jump into the one you linked. After you are able to boot properly we can get back to figuring out your harddrive situation.
is there a way to choot with USB iso live OpenMandriva ?
1 Like
I’m sure it’s possible, but I have not done so.
Look in Resources category.
Resources Index
yes I have done it multiple time, boot the live ISO:
mount -o remount,rw /root
chroot /root
work from there.
Specifically:
Both of those articles are Top Spot in the Resources Index that @rugyada referred everyone to. It has been 6 months or so since I have done this myself but I know of nothing that has changed in OMLx that would change either of those tutorials.
1 Like