Cannot transfer file due to "Filesystem does not support symbolic links" error

Question

When I want to transfer files from my local hard drive to my thumbdrive, I keep getting this error:

Filesystem does not support symbolic links. 

I don't know what this is, I need help with transferring files.

Dragging and dropping, does not work for me, the error appears. Right-click on the file and select copy, and then right click on the thumbdrive and select Paste does not work, I am still getting the same error.

Solution 1

A symbolic link is a file that points to another file, a kind of alias for a filepath. It is not compatible with the FAT-32 filesystem commonly found on USB drives.

To find the symbolic link, you can open the terminal and do an ls -al in the directory you are having problems with - the symbolic link will have an l as the first character in the listing (where directories have a d). Or else, you can do a find DIR -type l where DIR is a directory that might (indirectly) contain symbolic links (. is ok too).

If you want to copy the content: ls -al LINK, where LINK is your link, will tell you where it points to (if LINK is a directory you will have to remove the final slash in case you have one). Just copy that.

N.B.: ls -l is normally sufficient, I just added the a in order to display hidden files, whose name starts with a dot - for the case where the link is a hidden file.

But, if you are afraid of the terminal: in Nautilus (the file browser), the icons of links are marked by a small arrow on the bottom right (but not all icons marked like that are links). If you right click on the icon and select Properties, if it is a link, its Type will start with Link to, and its Link target will tell you where the real stuff is (unless that is a link itself, in which case you will have to follow the chain).

Solution 2

If the copying is done in some shell terminal (i.e. bash), then cp can be explicitly told to copy the file that a link points to with --dereference, instead of the link itself. The default behavior of cp is to copy files by following their links, but many graphical file browsers seem to have a default behavior of attempting to copy links and generally perserving most attributes.

man cp

-a, --archive
       same as -dR --preserve=all

-d     same as --no-dereference --preserve=links

-L, --dereference
       always follow symbolic links in SOURCE  

---

Example

touch SomeFile.txt
echo "some content" > someFile.txt
ln -s -T someFile.txt someLink
echo "Some content for the test file." > someLink
mkdir someDirectory
ln -s -T someDirectory someDirLink

The fact that someLink is a link, is shown by the l flag in the first position of the listing output (and `d' designates a directory).

ls -l

drwxrwxr-x. 2 user group 4096 Aug 17 17:17 someDirectory
lrwxrwxrwx. 1 user group 13 Aug 17 17:17 someDirLink -> someDirectory
-rw-rw-r--. 1 user group 32 Aug 17 17:01 someFile.txt
lrwxrwxrwx. 1 user group 12 Aug 17 17:12 someLink -> someFile.txt

The file contains the content, and the link points to the file, but can be used in nearly any manner the file could be. (Note the link file size vs the text file size: 32 Bytes vs 12 Bytes.)

cat someFile.txt

Some content for the test file.

cat someLink

Some content for the test file.

First, copying the link to a directory. Then copying the file to the directory, through the link. (The below also shows that directory links work in a similar manner to file links.):

cp -a someLink someDirLink/newCopy
cp -L someLink someDirectory/newCopy.txt
ll -l someDirLink/

lrwxrwxrwx. 1 user group 12 Aug 17 17:12 newCopy -> someFile.txt
-rw-rw-r--. 1 user group 32 Aug 17 17:36 newCopy.txt

---

Caution

Links can be made to point to a full path or a relative path. Since this example used a linking based on the relative path of the target being in the same directory as the link being created, the link was broken when it was copied to a new directory.

cat someDirLink/newCopy

cat: someDirLink/newCopy: No such file or directory

cat someDirLink/newCopy.txt

Some content for the test file.

Solution 3

you can simply compress the folder and then copy it as you like

Solution 4

The file you are trying to copy is apparently a symbolic link, which just points to another file. Removable media typically are formatted with a Microsoft filesystem such as FAT32 or NTFS, which do not support symbolic links, so you can not place one on the drive. Note that copying just the link would not do any good anyhow since having the link without the file it points to would be useless.

Solution 5

Your thumbdrive/pendrive is probably formatted as FAT32. Try formatting it as NTFS (Make sure to backup it's content first). Of course, EXT3/EXT4 support symlinks too - but you'll have compatibilty issues with non-Linux systems then.
Check out this related thread.

But, as psusi correctly mentions - copying a symbolic link can create more problems because it might point to a file or folder on your local harddrive and therefore will not be accessible from other computers. Symlinks are preserved if they are relative symlinks (e.g., pointing to a directory above the current directory).

According to rumors NTFS-formatted pendrives tend to wear out earlier. This is not verified :). [Edited]

View more solutions

Comments

[owl]

dragging and dropping, does not work for me, the error appears. right click on the file and select Copy, and then right click on the thumbdrive and select Paste does not work, I am still getting the same error.

[Thomas Ward]

I disagree with your part about NTFS_formatted pendrives wearing out faster. I have a 8GB USB flash drive from at least 7 years ago, and its formatted NTFS. It still works. Also, relying on yahoo answers for things you are quoting as advice is not exactly a good thing.

[psusi]

Indeed, the wearing out faster is FUD, and more importantly, NTFS also does not support symbolic links.

[Mateng]

I wasn't aware that it is bogus, good to know. I changed my wording. NTFS however does support symlinks. I guess NTFS is the better choice, because a flashdrive formatted in EXT3/EXT4 can't be read from non-Linux systems.

[Mateng]

NTFS does well support symbolic links, however they are in Interix format. They are usually converted in Ubuntu when using the ntfs-3g driver. But I agree on your opinion that copying symlinks itself might create more problems.

[Sourabh]

This should be the accepted answer

[jawtheshark]

That very much depends on the archival format and what options you used.

[Necktwi]

macOS is able to create symbolic links on my exfat drive. so it should be problem with linux/driver rather than with filesystem. This inability totally makes git useless to clone projects to my exfat drive, which I use cross platform.

[VoteCoffee]

Genius. It's a simple solution that did exactly what I needed.