I can no longer open my password-encrypted LibreOffice Calc file – nor hourly/daily/weekly/monthly/… rsync backup copies of that file, on a separate (local) hard drive.
"The password is incorrect. The file cannot be opened."
I was able to access that file two weeks ago (end of Jan 2021).
I recently (coincidentally around but just after that time) replaced my main hard drive and restored it using the most recent rsync backup. However, relative to this issue that HDD only contained data files.
My Linux system (hence, LibreOffice) is installed on a separate (pre-existing) SSD/partition, and the backups reside on another (separate, pre-existing) HDD/partition.
Thus, as far as I know the HDD replacement should have nothing to do with the ability of LibreOffice to open the password-protected .ods file (or the backups). That suggests that a recent version of LO has mangled the password protection on files it has processed (protected)?!
It is not a Caps Lock, nor a file permissions … issue (I checked), and the fact that I cannot open open older archived backup copies indicates that it is a LibreOffice Calc issue.
Interestingly, I can open older copies of LibreOffice password-protected files (rsync archived backups, albeit password-protected using older versions of LibreOffice.
I downgraded my Arch Linux LibreOffice installation to some earlier versions (most distant tried: libreoffice-still-6.4.7-8), without success in opening that LibreOffice password-protected file.
What is the issue/solution?
uname -a Linux victoria 5.10.16-arch1-1 #1 SMP PREEMPT Sat, 13 Feb 2021 20:50:18 +0000 x86_64 GNU/Linux libreoffice --version LibreOffice 126.96.36.199 00(Build:2) pacman -Ss libreoffice | grep installed extra/libcdr 0.1.6-3 [installed] extra/libreoffice-still 7.0.4-1 [installed]
In response to @ajlittoz :
I can copy the “myFile.ods” file (here, pseudonymed “myFile”), and I can open (Linux File Roller/archive manager) myFile.zip : “Configurations2/ | META-INF/ | Object 2/”
The main (replaced) HDD is not encrypted / password protected, but as the drive was physically replaced, it has a new UUID:
sudo blkid /dev/sdc1 /dev/sdc1: LABEL="vancouver" UUID="82513f0a-6484-4d04-8570-df0f1693df3d" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Vancouver" PARTUUID="be58fd74-0c99-4528-8e62-f8fea78fd822" cat /etc/fstab | grep sdc1 # /dev/sdc1: "/mnt/Vancouver" [6TB Seagate IronWolf (2021-02-01)] # /dev/sdc1: LABEL="vancouver" UUID="82513f0a-6484-4d04-8570-df0f1693df3d" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Vancouver" PARTUUID="be58fd74-0c99-4528-8e62-f8fea78fd822" # └─sdc1 8:33 1 5.5T 0 part /mnt/Vancouver
Although I didn’t mention it, I was hoping that LibreOffice didn’t hash or whatever some identifier (like the UUID) from the hard drive. [In the off chance that it helps, I have the previous UUID recorded in my notes.]
Regardless, as I mentioned, ostensibly, that new HDD should have not have anything to do with this issue, as LibreOffice is installed on a SSD (as is /…), and I cannot open any of my rsync’d backups of “myFile.ods”.
Bug report filed [2021-02-16]: tdf#140456 (link reformatted by ajlittoz for better lisibility)