Announcement

**aria** · Oct 31, 2020, 01:30 PM

Narrowed the issue: The only files I cannot write (or overwrite) to a USB key are LibreOffice (.odt) created from my own generated templates (.ott) on my old OS 18.04. Not template .ott files, just writer documents created from .ott then saved to .odt. These files I cannot copy to any USB drive, in no directory. Any other files (even from the same folder, but not created from templates, can be copied. These files (created from templates), cannot be open with LibreOffice either (just in read mode). Any other files can. Note that my templates were already installed in the new LibreOffice, and still didn't work.
Any suggestions?

**claydoh** · Oct 31, 2020, 01:44 PM

What are the file permissions/ownership of the files that won't copy?
How is the USB stick formatted?

it sort of sound like general ownership or permissions problems, but most usb sticks are formatted with fat32 or exfat, which don't have file permission or ownership features at all.

**aria** · Oct 31, 2020, 02:51 PM

Writer documents (.odt) created from my own templates won't copy to any USB drives (fat32 or NTFS) after moving from 18.04 to 20.04, and recovering the backup of all files in my Home directory. Tested both, Fat32 and NTFS drives.
Also tested if newly created files from templates (both templates, LibreOffice and mines) would copy to USB, and they do! Only the old ones (created in 18.04) won't, even if modified and saved write now.
Home directory backup and recovery were done the simple way, by copying, not by archiving. So, from USB to computer these files could and can be copied, but from computer to USB not anymore. Also note that my templates are the same, just imported them from backup to the new LibreOffice.
Permissions are the most permissive (anybody can read and modify the content), so this doesn't seem to be an issue. Nor the space on the USB drives. Nor the folders where I try to save these files (tried even on newly formatted USB keys, and didn't work).

Looks like it is a LibreOffice issue, but how can this app control the copy process to USB, while closed? Should have set a policy somewhere in the system or in my Home directory. Of course I also tried from LibreOffice, saving as / to USB, and as expected didn't work either.
Any enlightening?

**claydoh** · Oct 31, 2020, 04:39 PM

No idea. Maybe someone has seen this on Libreoffice's forums?

**aria** · Oct 31, 2020, 04:48 PM

OK, found something new:

From the laptop I open the file (the one refusing to copy to USB), then I "save (it) as" with a totally different name in the same directory on the laptop. And surprise, I can copy the new file it to USB, despite the fact it is the same with the one refusing to copy, just with another name.
But, if after open it, I open a new empty file (to erase any template traces) and copy only the text in it, then save under the old name adding a number at the end to distinguish it from the original, the new file doesn't copy to USB. Even if there are no traces left of the template.

This means it isn't a template issue: the template within the file passes, but the name doesn't even if a number added at the end.
Looks more like an indexing issue. But I deselected File Search in the System Settings from the beginning (first thing after installing 20.04, even before the first update).
Any idea what is this and how could it be corrected?

**jlittle** · Oct 31, 2020, 05:15 PM

(This is interesting.) Maybe there's an ACL (access control list), or a "SELinux context" attached to the files.

If you run

Code:

$ ls -lZ example.txt
-rw-r--r-- 1 john john ? 1270 Jun 15 15:06

for the uncopiable files, does the Unix permission string have anything other than a space after the "rw-r--r--", or is there anything other than a "?" between the group and the size?

If there are "extended attributes" attached to a file, something (I've only ever seen a "+") shows after the r--. On some (or maybe most or maybe all) Linux file systems ACLs are stored in "extended attributes", aka "xattrs". ACLs are an OS-agnostic permission system that pre-dates Linux and Windows NT, and on the few times I've had to deal with them I found it tedious.

I know nothing about "SELinux contexts", or if or how they work with ACLs, other than their name, and the -Z flag to ls. But I presume they might have something to do with permissions.

**Fred47** · Oct 31, 2020, 05:39 PM

One more thing to note in Linux with ext4 you can have file names with special characters like : ? and more that are not compatible with Fat32 or NTFS.

**aria** · Oct 31, 2020, 05:54 PM

Not sure I understood, but I run the first line, changing "example.txt" with the path to the .odt file. Said: command not found.

But narrowed the issue even more: the only files not copying to USB are the .odt created from a template having in the header a title plus the date and time fields. And this header I copied to the file name when saved. But, if I save this file with another name, or even rename it in Dolphin, or even more, if I cut the date and time in its name, I can copy it to USB.
Ex: The file not copying to USB was called "Category - Subject 2019-06-03 (11:23).odt". The name, date and time were copied when saving the file, from the file's header (where the date and time are special fields). Adding at the end of the file name a letter or number, like in "Category - Subject 2019-06-03 (11:23)2.odt", doesn't allow it to copy to USB. But if I cut the date and time in the file's name and leave just "Category - Subject", it will copy to USB.

Any other document (.odt) created from a template not containing any date or time field (so not in the file name either), can be copied to USB.

All these files were created when I used 18.04, then backup by copying to USB before installing 20.04, then copied back to the new Home directory from USB. Then, I opened one of these files to add some text (write a new idea) and saved it. But when I tried to backup the modified file to the USB, it refused to copy (overwrite its old version). Tried same thing with a non-modified file, and refused to copy (overwrite) either. All these files were of the kind described in this post.

Does this says something?

**jlittle** · Oct 31, 2020, 07:05 PM

Originally posted by aria View Post

Not sure I understood, but I run the first line, changing "example.txt" with the path to the .odt file. Said: command not found.

"ls" was the command, I put $ there to indicate the shell prompt. But,

Originally posted by aria View Post

Does this says something?

That's it. You can't have colons in FAT32 or NTFS file names. I expect you are familiar with Windows drive letters, giving the typical Windows file name, for example,

Code:

c:\Users\aria\example.txt

Everything before the colon is interpreted as the "drive". In principle, Windows doesn't need a drive letter, for example "//server/example_path/example.txt" but its users still cling to the drive letters, because it's handy to map a long server path to a letter.

(Unix path names can have any character at all except / and the NUL character. But it's not a good idea to use things like control characters, illegal utf-8 sequences, non-graphics, oddballs like ⧸ ．۔ (not the ordinary characters they look like), or characters not in the system font.)

**aria** · Oct 31, 2020, 08:22 PM

File names are right, I used them with no issues in 18.04, on Fat32 and NTFS too. Actually NTFS accepts almost all characters and even similes and all kind of signs (stars, etc...), and this is why I store on NTFS formatted drives my YouTube and torrent downloads.

But here is something new: I tried all the copy procedure described in my posts, on another machine, a lazy old netbook I use mainly to play music (thus the name I gave it, Radio). This machine runs very well but slowly on Neon, recently upgraded to 20.04 with Plasma 5.20 (Kubuntu 20.04 runs Plasma 5.18). But being so slow, I didn't install on this machine LibreOffice, but Caligra, to have an .odt file viewer (+/-editor). And what a surprise: copied the files in question here, from USB to a directory in Neon, and when tried to copy (overwrite) them back to USB, the system refused to do it, just like in Kubuntu.

Thus, I believe it is not a LibreOffice issue, but a file name format one, due to a change either in 20.04, or in later Plasmas. Should this be because of the date and time format I used in the name of these files, format that conflicts maybe in 20.04 (or Plasma 5.18+) with, let say, some image name formats, adopted, let say again, on phones OS? Should this be a newly introduced protection/policy, 18.04 didn't had?

What do you think?

**jlittle** · Oct 31, 2020, 11:26 PM

I doubted the story, so I booted up a bunch of old distros... an old systemrescuecd USB that warned me to use ntfs-3g to mount an ntfs volume. So, I did ... and colons worked...

Back in 20.04, I noticed have ntfs-3g, I don't know why, so I unmounted the ntfs backup disc I was testing with, then mounted it with ntfs-3g:

Code:

sudo mkdir /mnt/work
sudo ntfs-3g /dev/sdd1 /mnt/work

and now in Kubuntu 20.04 I can create files with colons in their names.

So, you're right, Kubuntu's handling has changed. The ntfs driver in Linux has improved over the years, MS didn't really help. But I imagine that the one we use now is better than it was, but disallows colons.

Now, I don't recommend using ntfs-3g. Some of the files I created while booted with systemrescuecd disappeared when I started up Kubuntu. And I suggest using dots or hyphens in timestamps, for example
example.2020-11-01-18.04.02.txt

**aria** · Nov 01, 2020, 09:17 AM

Thanks John.
Now that I narrowed all this issue to the format of the file name, I wont change the system for some old (but precious) files I have. Instead I'll change the name of these files until they'll copy to USB, while still preserving the information I need to organize their view in Dolphin (date and time within their name).
Bests,
PS: Issue is far larger, see next post.

**aria** · Nov 01, 2020, 09:54 AM

So, the issue I encountered is deeper than I expected: FUSE and ntfs-3g.
This is very annoying as it prevents me to backup 2+TB of downloaded music and video files. Out of question to change the names for all these files, to eliminate colons.

But, have the codes you suggested above, a permanent effect on the user's settings, and applying to any other USB ntfs drive (I mean without running them for each new drive)? Would like to know these before trying.

Thanks,

**aria** · Nov 01, 2020, 10:54 AM

Did run the codes you suggested and:

Code:

username@MACHINE:~$ sudo mkdir /mnt/work
[sudo] password for username: 
mkdir: cannot create directory ‘/mnt/work’: File exists
username@MACHINE:~$ sudo ntfs-3g /dev/sdb1 /mnt/work
username@MACHINE:~$

Did mount the drive manually before exiting the terminal, and could indeed copy a file with colons to it (to do this, I created an empty text file named Test:File?ntfs!.txt).
But these codes were one shut: at a second mount, after exiting the terminal, and I couldn't copy that file anymore.

Later comment: At a second plug, sdb1 mounted at the default point: /media/username, not at /mnt/work, so this could explain the one shut. Thus, tried the same codes with the default mounting point /media/username, and first worked. But at a second plug into USB, when sdb1 mounted at the same location, ntfs-3g retrograded to read-only, writing being ensured only by the ntfs settings within the kernel.

How could be set FUSE to a default value ntfs-3g for all sdb mounted ntfs drives (just like it was in 18.04)?
Thanks,

Announcement

cannot write to usb drives

cannot write to usb drives

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment