I wrote a bash-script with the intention to back up a specific (truecrypt-)file onto a SD-card (and a folder shared over the cloud) using the rsync command.

The problem was that the SD-card usually wasn't mounted yet and thus the synchronization didn't work. So I wrote a script that mounts the card, syncs the file and should unmount it again. Script:


sudo mkdir /media/user_name/SDcard
sudo mount -t vfat LABEL="SDcard" /media/user_name/SDcard

rsync -avI /home/user_name/Dokumente/file_to_sync /media/user_name/SDcard
rsync -avI /home/user_name/Dokumente/file_to_sync /home/user_name/cloudbox

sudo umount /media/user_name/SDcard
sudo rmdir /media/user_name/SDcard 

While the synchronization to the cloudbox works properly, the sync to the SDcard does not. Furthermore the umount and the rmdir commands both are not executed. The result being that the following time I use the script, there is an error because the directory already exists.

When all commands are executed manually and in succession in the terminal, the rsync command (with sudo) to the SDcard gives an error message:

user_name@host ~ $ sudo rsync -av ~/Dokumente/file_to_sync /media/user_name/SDcard/file_to_sync
sending incremental file list
rsync: chown "/media/user_name/SDcard/.file_to_sync.tK2RnM" failed: Operation not permitted (1)

sent 524,416,101 bytes  received 127 bytes  61,696,026.82 bytes/sec
total size is 524,288,000  speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.0]

Strangely, if I mount the SDcard by double clicking on the desktop icon instead of using sudo mount ..., I can synchronize the file without any problems.

What is wrong with my script? I have tried several modifications, but none worked (better).

Why is there a difference between the mounting by double clicking and the mounting in the terminal and what is it? How could I "reproduce" the "double-click-command" in the terminal?

I have been trying to get this to work for quite some time now and forums and tutorials etc. could not help me out. So I'd appreciate any tiny little bit of help anyone can give...


My System: Linux Mint 17 (originally Cinnamon but changed to XFCE) on a Lenovo T440p with CORE i7vPro, 250 GB SSD, 12 GB RAM (and the worst touchpad I have ever encountered)

  • 1
    You really want to set -e early in the script, rather than blindly continuing when there's an error. Also, consider looking into pmount for user-accessible mounts (or add user to the mount options in your fstab). Feb 2, 2016 at 16:03
  • @ Toby: Thanks for the set -e idea. I included set -ex so I could see the commands executed step by step. It does make things easier. I have tried pmount just now and it worked, at least partially. There are still some issues to resolve but I think that' s the way to go. Thank you for the help. About fstab: How would I add user and what exactly would the effects of it be?
    – cain
    Feb 3, 2016 at 11:34
  • @ Toby: pmount worked great. Thank you.
    – cain
    Feb 3, 2016 at 19:43

1 Answer 1


So it's a permissions problem. The FAT filesystem mounted by root cannot be accessed by normal users.

It's a result of the fact that FAT doesn't include ownership information, so all files are considered owned by the user who mounted it.[1] The chown error message is because you're trying to copy files owned by you, to the FAT filesystem, using the -a option which preserves ownership information. But you can't make files owned by your user there, they have to be owned by root.

You could run rsync with sudo too (edit: you'd also need to add the --no-owner option), or add -ouid=$USER to the mount command.

Or you could use udisksctl or udisks to mount using the udisk daemon instead, which is what your graphical desktop interface is doing.[2]

Edit: I forgot udisks looks slightly different to mount, sorry. I use udisksctl mount -b /dev/... So it doesn't obviously support the LABEL= syntax. You can use the symbolic links (shortcut-like files) udev creates instead. udisksctl mount -b /dev/disk/by-label/SDcard.

Udisks will choose the mount point for itself; the path will use filesystem identifiers like the label so as long as those are unique then the path will be consistent... which may not be ideal, ho hum.

I think you can set the mountpoint udisks will use manually by creating an entry in /etc/fstab. GNOME Disks has a graphical interface for this (Select the disk and then the partition, click the cog underneath, Edit mount options). If you want to use the "old" mount command without sudo, you can even add "user" or "users" to the list of mount options (see man mount and man fstab for the difference between those options etc.).

[1] Native Linux fileystems like ext4 are different from FAT; the filesystem records which user ID owns each file so it doesn't matter who mounts the FS. Windows NTFS supports user ID's too, but don't ask me how it behaves when you mount it with Linux.

[2] This will probably have some additional policy restrictions (polkit): by default you won't be able use udisks when you logged on to that computer remotely using SSH.

  • running sudo rsync [...] gave this error message: rsync: chown "/media/user_name/SDcard/.file_to_sync.gVfffc" failed: Operation not permitted (1)
    – cain
    Feb 3, 2016 at 8:36
  • Ah, apologies. I gave the correct reason why rsync without sudo would fail. However running rsync with sudo is not a solution, as you observe :). Assuming you have a current Linux distribution, it should support udisks. pmount is kind of a third-party thing - if you had to install it, you're slightly weakening the policy of your system as you describe.
    – sourcejedi
    Feb 4, 2016 at 15:32
  • I once tried the sudo su - before using rsync and it just gave back another error message (don't know what exactly any more). With udisks I am having trouble, I just haven't figured that out yet. The man page somehow does not explain much more than just what the commands do. I am missing the explanations and options and the internet didn't help much. Do you have any suggestions on where I could find something like that?
    – cain
    Feb 5, 2016 at 13:27
  • *slightly weakening the policy of the system as I described. Sorry for going all around the houses. I've added the exact udisksctl command I would try.
    – sourcejedi
    Feb 6, 2016 at 12:49
  • If you find this information useful and interesting, you might suggest how the answer could have been written better. It's the sort of question that comes up periodically, but I'm not aware of a good reference as you describe. Maybe there's one to be found in web search though.
    – sourcejedi
    Feb 6, 2016 at 13:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .