Bi-directional read/write bet. Trisquel 9 w/ Encrypted LVM, & Non-encrypted NTFS doesn't work, even w/ NTFS-3g Config Tool
- Inicie sesión ou rexístrese para enviar comentarios
I added the NTFS-3g Configuration Tool GUI, to hopefully allow/configure seamless bi-directional read/write between Trisquel 9 on Encrypted LVM SSD, and an internal NTFS-formatted HDD. That essence of the program (and several likely dependencies) was already reported as installed, but since it didn't work, I marked the program for re-installation and executed the instruction.
Kindly Trisquel users,
Reason: Could copy from NTFS drive and paste to Trisquel boot SSD drive, but NOT the reverse (copy from boot SSD and paste to NTFS-formatted internal HDD.
Result: 1. The 'NTFS Configuration Tool' was installed, but had no apparent effect to solve the issue...still reads/writes one direction ONLY (from NTFS to Encrypted LVM SSD w/ ext4.)
2. The Configuration tool GUI will not start, and reports exactly "No Authentication Program Found"..."ntfs-config need to be run as root, but I can't find
a graphical authentication program. You should install gksu or kdesu. Alternatively, you can run ntfs-config from the terminal with su or sudo.
Additionally attempted so far: Started the NTFS Configuration Tool from sudo in MATE terminal as suggested, and then added (check-marked) BOTH internal & external NTFS drives. No problems reported, but the issue still remains. Restarted the machine, and the check-marks were retained, tough the GUI still fails to star the program.
It seems that since the essentials of the "NTFS Configuration Tool" were already installed, by default, during the initial OS instillation (except the working GUI), in likely anticipation of the need to read/write bi-directionally between differently formatted drives, something has gone awry with either the tool itself, and/or any needed dependencies. I did search for the problem (at least to the limit of my ability regarding other fixes), but didn't find anything for which I felt capable, or even which adequately addressed the specific concern.
I earnestly do *appreciate+ assistance from more knowledgeable users, and ask kindly that any offered help be explicit in detail, "ex. Step 1, 2. 3 w/ details." I truly adore the efforts being made to free users from proprietary software/OS's!
Thanks so kindly for your attention...and please, EVERYONE, stay safe over the holidays, and throughout 2021!,
Earthling
One question: Have you disabled fast boot in Losedows 8.x/10?
That NTFS-formatted drive was the original HDD that came with the machine (and originally had "Losedows" as boot, before the SSD was added), but has since been ENTIRELY formatted (before doing that (I copied the data ONLY over to another external HDD, which I no longer have.)
So to your question, no, I don't 'think' there could be any "fast boot" (or other lingering Windows setting) left on that drive. Is there any way to check/correct (without formatting it), to be certain?
If so, I DO still have Windows-To-Go 10 on a USB stick, so could access that drive FROM Windows, if it would solve the issue in question?
Go back to Losedows To Go and check whether fast boot is still enabled. I can't figure out any other possible reason than fast boot. Or better yet, disable fast boot on any Losedows copy that may access the NTFS volume.
The fact is that GNU/Linux provides far far better support of NTFS via ntfs-3g than Losedows. Some damaged NTFS volumes that have been "sentenced to death" by Losedows disk utilities can be easily repaired using ntfs-3g. (Of course, you have to go back to Losedows to run chkdsk as the finishing touch.)
Fast boot is a major anti-feature introduced since Losedows 8. With it enabled, power losses can be much more deadly. It also significantly increases the risk of data loss. For example, I heard that someone "shut down" his Losedows 8.x/10 system and subsequently disassembled his computer in order to use the hard disk for some other purpose. He thought new data were written to the disk, but they were not, owing to fast boot.
Have you tried writing to the NTFS partition before installing ntfs-config? Trisquel has the package ntfs-3g installed by default. It should allow to both read from and write to NTFS.
Yes, I did try to write to that drive before installing ntfs-config, and I did see that it was already a default. I only tried looking for an answer when I realized it wouldn't write.
It was like this with Trisquel 8 as well; I just hadn't looked for a solution as yet, and was kind of hoping that I'd get lucky with the 'in place' upgrade (with which Magic had kindly helped me before), and only after that didn't resolve this issue (everything else was perfect), I went on to the full fresh install from scratch.
I finally was able to access/write to the non-writable NTFS drive from Trisquel. And I did turn off 'Fast Startup' on that Windows To Go USB (I think it actually is called 'Fast Startup', since the term "fast boot" as suggested by @nadebula, is perhaps more a BIOS setting on some computers, or with phones/devices?) However, since that Windows To Go USB was not the native OS, I don't 'think' it affected the write permission on the NTFS drive in question.
I also found that drive's permissions were different than the boot SSD, so with Windows, was able to enable both 'write' and 'full control', so that it matched the permissions on the SSD where Trisquel is installed. Perhaps if I'd known that before I could've also done this from Trisquel? If so, I didn't know how.
End result: I CAN now both read/write *bi-didrectionally*, using Trisquel alone, and since I'd already uninstalled the NTFS Configuration Tool from Trisquel (as suggested by @Magic), it seems likely that tool had nothing to do with regaining write access, and Trisquel does in fact offer the feature by default.
Could I have changed NTFS drive permissions from Trisquel natively, without booting from a Windows USB? I didn't know how to even look at the drives from there...but it seems likely someone else knows how to access them directly?
Sorry for the delayed reply! I needed to sulk a bit from being so lost and then come back to the problem, but apparently, for now, this issue is SOLVED. Thank you BOTH very much!!!
As I told you before, it was fast boot that prevented the NTFS volume from being written (but the mechanism has nothing to do with file system permissions). Fast boot doesn't work in the way you think.
Of course, I also hate to learn such anti-features of Losedows, but I have to do so in order to solve the really stupid problems caused by them.
@nadebula, FWIW, turning off 'fast startup', from within Windows-To-Go 10, did not appear, in itself, to affect the write ability to the drive in question, from within Trisquel. Turning off fast startup, restarting, and going back to Trisquel, gave the same exact problem...no write capability to the NTFS-formatted drive.
The fix (if it in fact persists), only came about after I had BOTH turned off fast startup from WTG, AND changed the write permission on the drive itself from WTG. If one can change such write permissions from within Trisquel, on an NTFS drive, I just didn't know how.
Perhaps Windows fast startup had something to do with changing the write permission in the first place, but I cannot speak to that...and must leave it to others far more knowledgeable.
I feel VERY lucky to have solved the issue, regardless of why/how it was corrected! Thanks everyone...really.
- Inicie sesión ou rexístrese para enviar comentarios