TL;DR

When creating a partition, the "Disks" application/utility sets permissions to 700 by default (read/write/execute access for the disk owner only). You'll want to change that if you've got multiple users who need to access the disk on your computer. I'll discuss solutions below.

Background

I ran into this problem and initially thought it was something to do with an encrypted partition I created under one user profile (User A, let's say). It turns out it has nothing to do with the encryption; it's all about the default permissions given to the disk once it's been partitioned. Let's have a quick look at what happened.

I'll assume you know how to create a partition via Ubuntu's "Disks" application. Let's say that's done, and that it's an encrypted partition. We log out of the user profile we used to create it (User A), and log into another one that will want access to it (User B). We find the disk with User B and try and mount it:

As you'd expect, you're prompted for the encrypted disk's password. Ubuntu offers you the option to remember the password (SIDE NOTE: this password gets stored in the "Passwords and Keys" utility--if you'd like to save and delete it later). Under normal circumstances, you'd expect this to be the one and only time you need to enter a password for this disk. Since, however, User B, doesn't have any permissions on the disk, we get some rather interesting behavior: you'd think Ubuntu would just fail to authenticate the disk (or not mount it at all), but instead we get this:

If you're not careful, you might think you're being asked for the disk's password once more. Nope. This is a request to authenticate User B. Why would I need to authenticate user B? I've already logged into the user's account--and, when have I ever needed to authenticate a user just to open a disk? Stop for one moment, though, and think carefully: when does Ubuntu ask you to authenticate your account? It's almost always when you need root (sudo) permissions. If your user has zero permissions on the disk, however, this makes perfect sense: in order to open it you'll need to access it as the super user root.

You might be tempted to brush this all off: mounting the disk as root will allow you to open it up and look inside it's contents. If there's more than one document on the disk you need to access, though, the situation is going to grow old in no time at all. That's because, for each document you try to open, you'll get this:

That's right!--you don't have permissions on anything inside the disk either, so you'll need root permissions for these as well! It won't take much of this before you start to wonder if there's something funny going on with this disk. It took me a while to realize why User B was being asked to constantly re-validate, but no matter how you dress this up it's obviously a permissions issue. If we hit the command line and go look at the disk permissions, we'll see exactly what's going on:

To get this output, we cd our way to the directory Ubuntu mounts our partition to; this should normally be the under the /media/user path. Since this path is beneath our user folder, we'll need to use sudo if we'd like to make any changes here. ls with the -a and -l options will list everything in the directory (hidden or otherwise) alongside permissions (you don't need the -a option, here--I just deal with a lot of hidden files on the day to day, so it's a habit--ls -l would do fine). Here, we can see that some loser named David (User A) is the only user with rights on this disk. Again, this has nothing to do with the disk partition being encrypted; it's just Ubuntu being derpy. We can't even really blame David--as big a loser as he is for not understanding default permissions...

If you're unfamiliar with permissions in Linux, let's break down the output above. The permissions on "Extras" are drwx------

• d = directory
• rwx = read, write, execute

The first letter (in this case, d) represents the type of item; "Extras" is a directory, hence the d. The next three letters after that represent the permissions for the owner: in this case read, write and execute (rwx); the following three (in this case empty), are the permissions for the group the user belongs to; the last three (again, empty above) are the permissions for others. When the owner is the only one with permissions on a file or directory, this is also abbreviated as '700' (the three digits again corresponding to the three kinds of users). Since encryption on this disk is more than enough to limit the people who can access the disk, I really don't mind giving all user groups rwx access--changing the permissions to '777'. I can do this on the command line with chmod; find your way to the parent folder for the file/directory/disk and run sudo chmod -R 777 file_or_directory_name:

That will do the trick! Be sure to include the -R option so that the change is extended to the contents of the disk recursively. Ubuntu should no longer prompt you for your password, regardless of which user is logged in!

Another Solution

In the end, the issue is entirely one of permissions; however, depending on your situation you may not want to give ALL users permissions on your disk/file. Another solution might be to ensure that other users you'd like to have access to the disk/file are in the same group as the owner--then, give rwx permissions to both the owner and group. Unfortunately, Ubuntu doesn't seem to have a graphical method for managing users in this way. If you look back to that last screen grab, you'll note that ls -al listed both the owner and the group to which the disk belonged (in my case, the owner and the group had the same name--David).  I could simply add other users to that group, ensuring (again, with the help of chmod that they also have permissions). If you're not clear on the who the owner/group a disk/file belongs to, you'll definitely want to rerun ls -al; if you'd simply like to see what groups a user belongs to to, you can also run id username--the first group listed should be their primary group. You can then append a user to that group with the following: sudo usermod -a -G groupname username. The -a option is to append; the -G option ensures it's to a group. Once this is done, you can confirm by running groups username. Here's an example from my own computer:

Once you've done this, you'll want to then find your way to the parent directory of the disk/file and run sudo chmod -R 770 file_or_directory_name. This would limit access to only the Owner and members of the Owner's group. In my case, encryption on the disk makes this pretty moot. If, however, your disk is without password protection, this option might have some appeal; it should prevent "other" users (guest users, or users not in the group who don't have root access) from accessing the disk/file.