I've recently installed Ubuntu 12.04 LTS (minimal virtual machine) on a VPS host. I've encrypted the virtual disk and encrypted the home directory of my main user account, that I'm using to access the install through SSH (using public key authentication). So far, so good.

The thing is: I can't figure out what exact action it is that is making my hidden files appear and active (such that I am able to use aliases, such as ll).

When I sign in initially with SSH and issue ls -al, all I see is:

dr-x------ 2 username username 4096 Feb 10 01:10 .
drwxr-xr-x 4 root     root     4096 Feb 10 01:10 ..
lrwxrwxrwx 1 username username   56 Feb 10 01:10 Access-Your-Private-Data.desktop -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
lrwxrwxrwx 1 username username   34 Feb 10 01:10 .ecryptfs -> /home/.ecryptfs/username/.ecryptfs
lrwxrwxrwx 1 username username   33 Feb 10 01:10 .Private -> /home/.ecryptfs/username/.Private
lrwxrwxrwx 1 username username   52 Feb 10 01:10 README.txt -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt

(As an en passant: why are permissions set to lrwxrwxrwx for most items here? Isn't that far too tolerant?)

Then, when I issue ecryptfs-mount-private (as per the README.txt) and issue another ls -al, I keep seeing the same as above.

One time, I believed I was able to use aliases after I issued a sudo command, but another time I was not able to. Then, another time I issued cd /home/username (which is the same directory as ~ already, is it not?), and all of a sudden all other hidden files appeared and I was able to use aliases.

But now, after a few minutes in (but perhaps I've actually imagined this), even though I'm still able to see all the hidden files, I'm not able to use aliases anymore. This makes me believe this behavior is somehow coupled with sudo, but I can't seem to figure out what exactly is going on here.

Can somebody enlighten me and explain what exact actions I need to undertake to see all hidden files in my home directory and enable aliases, and why this is (is it because of the encryption; is it coupled with sudo; or perhaps something completely different)?

If possible, preferably, I'd like this to automatically be enabled when I login with SSH. Is that possible?

edit (clarification for Hauke Laging's comment):

When I log in with SSH and immediately issue ll in ~, I get -bash: ll: command not found. (Although now, it appears to work immediately after I logged out and logged in again, but perhaps this is because the other time it was the first time after boot up? I have no idea, really. It all appears to behave rather random.)

Then, one time, I believe I issued a sudo ls -al, or some other inane command, after which ll appeared to work.

Another time ll didn't work, and only after I issued ecryptfs-mount-private and did an explicit cd /home/username, the hidden .bashrc (etc.) files appeared with ls -al, after which I was finally able to use an alias such as ll.

But, you know what? I think I'll have to investigate this a bit more thoroughly, since my vague descriptions are probably getting us nowhere. I was hoping my problem would immediately ring a bell, but it appears I have to be a bit more precise about what actions I undertook.

What I am trying to accomplish though, is this:

When I log in through SSH (whether it be the first time after boot up, or any other time after that), I want all hidden files, in my home directory, to appear immediately when I issue ls -al and that aliases, such as ll, are immediately available as well.

My analysis of the problem, thus far, is that it appears that I first have to decrypt my home dir, before I am able to see the mentioned hidden files (apart from the ecryptfs-related symbolic links) and use aliases. Is that a correct assessment?

  • Please explain more precisely what you mean by you cannot use aliases and when and how exactly you use sudo. Feb 11, 2014 at 11:36
  • @HaukeLaging I've edited my question for you. Please have a look and see if what I'm trying to accomplish makes sense. Like I mentioned though: perhaps I have to investigate a little more thorough first, for you to be able to assess the problem correctly. Feb 11, 2014 at 12:07
  • I have added some info to my answer. Feb 11, 2014 at 17:46
  • 1
    Display of hidden files (files whose names start with .) is controlled by the -a or -A option of ls (-A is like -a except that it omits . and ..). Whether ll shows hidden files depends on how ll is defined. The permissions of a symbolic link are unimportant; it's the permissions on the target file that matter. Feb 11, 2014 at 18:04

3 Answers 3


Situation: you have an encrypted home directory.

Step 1: you log in over SSH. Your encrypted data is not mounted, so what you see is your “real” home directory on the (unencrypted) main filesystem. This home directory doesn't contain much that's directly usable:

  • ~/.ecryptfs/ contains control data for your encrypted data
  • ~/.Private/ contains your encrypted data in encrypted form
  • ~/Access-Your-Private-Data.desktop is a desktop icon to mount your private data
  • ~/README.txt contains human-readable instructions to mount your data.

Your .bashrc and other dot files that you're used to aren't available because they're on the encrypted volume that isn't mounted.

Step 2: you run ecryptfs-mount-private. This mounts your encrypted data to ~ (your home directory). After that point, ls -lA ~ will show your dot files such as ~/.bashrc. If you run a new instance of bash, it will therefore read your .bashrc and you'll have your aliases available.

A subtlety is that after step 2, the current directory of your interactive bash shell is still the home directory on the non-encrypted volume. Mounting the encrypted volume on ~ changed the directory that ~ refers to, but does not change the directory that bash has open¹. If you run cd ~ in bash (or the shortcut cd), it will change its current directory to what is now called ~, even though this won't affect the value reported by pwd.

If you log in over SSH while your encrypted home directory is already mounted, then as soon as your login shell starts, it sees the files in your encrypted volume, so your aliases are loaded. Mounting an encrypted volume (or any other filesystem) is a global action, it is not confined to a login session. If you run ecryptfs-umount-private, that makes your encrypted data unavailable, back to the boot-time state.

¹ Technically, this is the current directory of the bash process, not an open file, but the behavior is the same.

  • Excellent answer! Thank you very much. It's all perfectly clear, and it all makes sense now. I'm still curious to know though: what would actually happen if I didn't run cd ~, right after ecryptfs-mount-private, but did touch test, for instance, in stead? Would that mess up the filesystem (I doubt it, but still...)? Or would bash give me an error perhaps? What is the status of "the current directory of the bash process" at that moment, so to speak? Feb 11, 2014 at 19:05
  • @fireeyedboy The test file would be created in bash's current directory (which is inherited by touch, which is the directory that's hidden by the mount point. Feb 11, 2014 at 20:16

Mounting does not change your current working directory. I guess that the mountpoint is the directory you are in. You either have to do the mount from elsewhere or to get out of that directory:

ls -al
ls -al
cd ..
cd -
ls -al


cd ..
cd -
ls -al

All symlinks have lrwxrwxrwx. This doesn't matter as the access rights of a symlink are never used. Those of the target are used instead.


Mounting means that the content of the mounted volume is shown instead of the content of the directory which is used as mount point. Applications see a one-dimensional file system name space. But that is just the projection of the two-dimensional stacking of file systems. Mounted volumes are higher than the root file system and cover parts of it (the respective mount point).

/dev/sdx:                        |mounted volume|
root FS: |---dir-1---|---dir-2---|---dir-3---   |---dir-4---|

You need certain tricks to access the covered parts. The trivial trick is: "Be there" before the mount (your case). The cool one is:

mkdir dir-1 dir-2
touch dir-1/file
ls -l dir-1 dir-2
mount --make-private --bind dir-1 dir-2
ls -l dir-1 dir-2
mount -t auto /dev/whatever dir-1
ls -l dir-1 dir-2


Random behaviour is obviously difficult to explain. Aliases are defined in both system-wide and per-user startup files (see e.g. man bash: invocation). Furthermore it may be a difference (depending on the configuration) whether the shell is called as an login shell or not. Playing with sudo may result in some shells being login shells why others are not. This would not be random, though.

  • About the symlinks: that makes sense. About the mounting — in layman's terms — are you saying I need to "refresh" the directory, in order to see the changes? Or is it something more complex (yet again. Getting kind of fed up with all this unintuitive complexity to be honest)? Feb 11, 2014 at 13:03
  • @fireeyedboy If you are in /home/foo, and you just mounted something on top of /home/foo, unless you cd out and back in, you're still in the underlaying /home/foo.
    – phemmer
    Feb 11, 2014 at 13:29
  • @Patrick What does "mounting on top" of a directory mean, exactly? Sorry for being dense; I just have a hard time visualizing/conceptualizing what all this is supposed to mean. I thought ecryptfs-mount-private would simply add the decrypted private files alongside the other contents in my home dir, but it appears to be much more complex than that. Are you saying the previous /home/foo "instance" is also still simultaneously available somewhere, and is not the same as the new /home/foo? Feb 11, 2014 at 13:45
  • @fireeyedboy Mounting on "top": when I mount an ntfs partition on my Linux it's mounted on /mnt/nt... once mounted I see the contents but the files are not "inside" the dir. If unmounted I would see an empty dir. I can put files in that empty dir. If I mount that partition again there, the files I see are the files from the partition, not those I would have added when unmounted. To see them I need to unmount and cd back to the top dir then cd back to the dir. There is an abstraction there. Hope this helps.
    – user44370
    Feb 11, 2014 at 18:20
  • Thank you for the addendum! I'm going to have to experiment with your mount example first, to understand the exact implication, though. It's not immediately apparent what it does. Is it safe to test this? ;-) Feb 11, 2014 at 19:14

Hidden files are files with a name starting with a period, they are not displayed unless explicitely requested, by using the -a option or specifically mentioning dot in the argument list. eg `ls -la or ls -l .*

file aliases are called links, they can be hard or symbolic. you have symbolic links there (the first character of permissions is an l denoting link), it is merely a pointer to the actual file, and it's the actual file's permissions which you want to be concerned about, not the link itself.

There is nothing that switches this behaviour on or off, if you are switching users (by using sudo) then remember as a different user you have different permissions.

aliases are setup by your shell when you login, (if your shell is bash) then check the man bash page and read about invocation, to see which start-up files it reads, usually .bashrc or .aliases is where they are established.

look at your ~/.profile you can add commands at the end such as ls -la if that's what you want.

Ubuntu website has an article about encryptfs might also help.

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.