My situation: I have a NAS which serves shares via CIFS/Samba. Internally, it uses an ext3 filesystem, but this is not relevant (I think). I have some Linux computers (using ext4 filesystems) which I want to back up on those shares.

My problem: Using the share for backups poses 2 main problems. On the one hand, I cannot copy all files to the NAS, because some files have very long filenames which CIFS can't handle. On the other hand, file and directory permissions are not copied correctly. For example, every file on the share has all the "execute" bits set, regardless of the original file's permissions.

My question: What is the easiest way to circumvent these "shortcomings" so I can back up and restore files without manually handling filenames and permissions?

Some additional info about my experiments so far:

  1. My first idea was to just create ext4 filesystems within (sparse) files on the share, then mount those and use them for the actual backups. The drawback here is that removing files from the filesystems doesn't decrease the size of the ext4 "files" on the share and the filesystems have to be limited in size from the beginning. It's cumbersome to resize them after creation.

  2. I tried to use ecryptfs because I hoped it would encrypt the filenames and permissions in a way that would get them around the CIFS limitations. This didn't work, since filenames are encrypted, but used as filenames again (so long filenames only get longer, not shorter). Also, permissions are not "hidden" by ecryptfs. The encrypted files just keep the permissions of the originals, so any decrypted file would again have all "execute" bits set.

  3. A friendly person on IRC recommended using a dynamic number of large files and use them as volumes for LVM. I have not tested this out yet, but in theory it should work. I would have a logical volume with an ext4 which would be spread among multiple files on the share. If I needed more space, I'd create more files and add them to the volume, if I used less space I could remove some. The only drawback here is that I'd still have to perform the resizes (and periodic checks how much space is actually needed). In retrospect, this provides little to no advantage over using single files, since I could truncate/grow them and then resize the ext4 filesystem as well.

  4. What I imagine is e.g. a FUSE which saves filenames and permissions in, say, a database and doesn't rely on the underlying filesystem to support everything. Unfortunately, I haven't fount anything like this yet.

  • Hmm, if the client is Linux, then it should be able to handle this using CIFS Unix Extensions (activated automatically)... [and CIFS certainly supports Windows/NFS ACLs as well]. It's more likely the NAS itself has a limited configuration. – grawity Sep 1 '14 at 5:54
  • This might be true. The NAS can actually even serve NFS shares, but these do not combine well with CIFS shares (serving the same folders) due to user IDs being different (plus it provides no authentication). I tried to hack around the NAS configuration (you can log in via telnet and it's running a small Linux), but this messes up the NAS, resulting an unstable web interface. In general, it's not very comfortable to play around with the NAS' configuration. – Fred Sep 5 '14 at 13:23

Samba with ecryptfs seems to be working for me on Ubuntu 14.04.

I used this guide: http://www.cyberciti.biz/faq/adding-a-user-to-a-samba-smb-share/

My hunch is that the trick is to give the same password in:

passwd USER


smbpasswd -a USER

I am assuming ecryptfs picks up the password when it is given to Samba, I would love to hear a clarification on how this happens.

  • Getting ecryptfs to work with samba (and the other way around) was not the problem. Files with very long names have very long names in ecryptfs as well and samba seems to be unable to handle such files. – Fred Jun 21 '16 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.