Symlink errors to CIFS drive

Asked by Jonathan

I'm trying to back up my new Fedora 11 linux home server to a network mounted drive. It's a FreeAgent disk formatted as HFS+ and attached via USB to an Apple Airport Extreme.

It's exposed to the linux box via CIFS on the local network. Here are the details:
---------------
The /etc/fstab auto-mounts the drive at /mnt/SBE via:

\\192.168.1.1\freeagent\040-\040server /mnt/SBE cifs credentials=/etc/sbe_creds,uid=0,gid=0,file_mode=0700,dir_mode=0700,perm 0 0

It's being mounted visible only to the root account (with permissions enforced) so other users on the linux system cannot access the data.
----------------

I set up BIT earlier today to back up most of the drive - the /home/ hourly, and most of the other / partition weekly. When I first started the backup manually to see what's going on. Here is the output I saw.

I'm a little concerned this may be a problem. I've read https://answers.launchpad.net/backintime/+question/76992 and also http://backintime.le-web.org/2009/05/10/files-not-copied-when-backup-directory-is-on-smbfs/ and am a little worried about my setup. I need/want to mount the drive over CIFS with permissions enforced, but unlike the le-web.org post, I do see some files stored on the remote drive.

Anyway, here are the errors. Will the symlink errors cause a problem? Or will it work but merely "take additional space" because symlinks will be dereferences during the backup forcing files to be duplicated (but only during the first snapshot)?

INFO: Call rsync to take the snapshot
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/awk" -> "gawk" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/csh" -> "tcsh" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/dnsdomainname" -> "hostname" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/domainname" -> "hostname" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/ex" -> "vi" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/gtar" -> "tar" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/mail" -> "mailx" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/nisdomainname" -> "hostname" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/ntfsmount" -> "ntfs-3g" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/rvi" -> "vi" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/rview" -> "vi" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/sh" -> "bash" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/traceroute6" -> "traceroute" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/view" -> "vi" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/bin/ypdomainname" -> "hostname" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/boot/grub/menu.lst" -> "./grub.conf" failed: Operation not supported (95)

NEWnavy:/root#226 -> jobs
[1] + 3134 Running /usr/bin/backintime-gnome
NEWnavy:/root#227 -> killrsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/etc/favicon.png" -> "/usr/share/icons/hicolor/16x16/apps/fedora-logo-icon.png" failed: Operation not supported (95)
 rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/etc/grub.conf" -> "../boot/grub/grub.conf" failed: Operation not supported (95)
rsync: symlink "/mnt/SBE/snapshots/backintime/new_snapshot/backup/etc/init.d" -> "rc.d/init.d" failed: Operation not supported (95)

Question information

Language:
English Edit question
Status:
Answered
For:
Back In Time Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Dan (danleweb) said :
#1

BackInTime copies symbolic link as symbolic links.

Check this link: "http://lists.samba.org/archive/samba-technical/2003-August/031055.html"
" Symbolic links are supported with the cifs vfs but only to servers, such as Samba (versions greater than about 2.2.5), that support the "CIFS Unix Extensions." "

So it looks like symbolic links are not available.

Revision history for this message
steve craig (cixelsyd) said :
#2

The solution is to modify your CIFS mount options and include nosetuids,noperm

See:

http://www.ikickass.com/shortthoughts/backintimecreatesdirectoriesbutfailstocreatefiles

Revision history for this message
Omk (ossi-viljakainen) said :
#3

It seems this cannot be solved - or has anyone so far been able to solve this symlink problem with cifs?

See #7 in https://answers.launchpad.net/backintime/+question/164397:

paulatz (justforspam) said on 2011-09-11: #7

I've tried for a long time to have backintime work on a cifs filesystem on ubuntu, but I have experienced the same problem as you which in the end forced me to give up.

After some testing I found out that the real cause in not a problem in backintime but some very difficult to reproduce bug with the cifs filesystem kernel module. When the cifs filesystem is used internsively, to create many files and/or copy a lot of data (it is not clear to me) it will eventually stop allowing the creation of new hardlinks until it is restarted (a full unload/reload of the module is necessary, just unmount/mount won't work). When this happens ,attempting to create an hardlink (with any mean) will just give a cryptic input/output error.

Unfortunately I have not (yet?) been able to reproduce it reliably and, afaik, it may depends on a bad client as well a bad server so I did not bother to report it.

Revision history for this message
Germar (germar) said :
#4

You could use 'copy links' in Expert Options. This will copy the linked file instead of the symlink. It will waste some space but at least it will work.

On the other hand if your destination supports SSH I'd recommend using BIT version > 1.0.12 with mode SSH. It's lot faster than CIFS because of rsyncs remote sync algorithm.

Revision history for this message
Omk (ossi-viljakainen) said :
#5

Germar -
Wow this is an amazing answer! I did not know my device supports SSH, but yes, it does. It was hidden, and actually can enable it. So I will certainly look into mounting the drive through sshfs. And I hope this tip helps also others with the same issue. Thanks a lot! :)

Revision history for this message
Germar (germar) said :
#6

I'm glad to help :-)
But don't mount the drive manually with sshfs. It won't work. Rather read 'man backintime' mode SSH section on how to prepare your system with password-less login and use mode SSH in BIT Settings. It will mount your drive automatically and do some other tricks in background, too.

Can you help with this problem?

Provide an answer of your own, or ask Jonathan for more information if necessary.

To post a message you must log in.