6 years ago
HOW TO SET A SHARED FOLDER BETWEEN MULTIPLE USERS OF ONE COMPUTER
(Tested on LM 17 Xfce 64-bit and LM 17.2 Cinnamon 64-bit)
First of all, please understand that this is NOT a standard tutorial: consider more as a solution that did work for me but that might work or not for you, depending on the particulars of your system.
One of the dauntiest tasks in Linux Mint is to set a working shared folder for multiple users of the same computer, which is pretty irrational, given that Linux itself is a fork of an operating system (UNIX) that was designed from inception as a multiuser environment.
On this "how-to" I am going to show you how to set all files and subfolders of one shared folder to be equally read and written (modified and/or deleted) by any user of a common 'group' that we are going to assign to this shared folder.
However, if you prefer the safest and most secure of all approaches to privacy in Linux Mint, then you might consider the following two steps option to prevent all 'others' users of the computer, remote or local, from being able even to view the contents of anyone's files and subfolders (thus restricting each 'other' user to those folders and files belonging to that particular 'other' user).
The first step is you must change the 'umask' argument from '002' to '007' (in all steps below where you set the 'umask' argument to '002') but remember that when you set a global 'umask' of '007' it affects ALL folders and files in that computer and no one, not even you, will be able to even view the subfolders and files of any other user unless the 'group' of that subfolder and its files belongs to a 'group' to which you both belong.
The second step is that, when creating a user (in step 02) you must choose the option to encrypt their 'home' folder (albeit bringing with it a slight performance penalty), thus preventing anyone without access to that user's password to view the files and subfolders located on that encrypted home folder (even if the peeping tom uses a LiveCD session to circumvent the permissions restrictions for the non-encrypted folders).
It is also important to note that setting an 'umask' of '007' will NOT affect the functionality (and the sharing) of the shared folder by its members.
STEP 01: Set a Global Umask of '002'
a.1) Disable MDM (the default window manager pre-installed in Linux Mint):
MDM is buggy and will prevent (at least in Linux Mint) a global umask of '002' from being enforced, forcefully reverting it to '022' and thus you must first get rid of it, otherwise nothing will work as supposed to.
To disable MDM and install LightDM on its place, use the instructions given on the first tip ("create a guest account in Linux Mint 17.2") found in 'Linux Mint: System Hacks for Advanced Users' at https://sites.google.com/site/easylinuxtipsproject/2 but BEWARE! I tried it on two computers (already fully configured and updated) and ended up getting a message at the login window saying 'failed to start session' for every local user installed on those computers, effectively locking me out of each computer (and forcing me to use a LiveCD session to retrieve all the data of each user's home to an exterior hard-drive before repartitiong the hard-drive as simply reinstalling the system without formatting the 'home' partition in order to preserve every user's personal settings will simply not work).
However, this method works flawlessly on a brand new installation with Mint 17 Xfce 64-bit or Mint 17.2 Cinnamon 64-bit BEFORE you run any update for the very first time and BEFORE you create any other user on the system.
From now on this "how-to" assumes that you are using a brand new Linux Mint installation.
Reboot after you finish this step 1.a and check your user 'umask' (simply type the command 'umasḱ' on a terminal and it will return the value of your 'umask'). Amazingly, the simple act of disabling MDM and installing another window manager will reset your 'umask' back to UNIX and UBUNTU's default (umask = 002).
a.2) Purge MDM from your computer:
MDM, even after being disabled as per step 1.b, will actually load into the memory during the boot up sequence (giving it a chance to mess with your umask). Thus, it is better to delete it completely from your system:
sudo apt-get purge mdm
a.3) [OPTIONAL] Remove the Ubuntu logo that appears on the lower left corner of the new login page:
Follow the simple steps described on this tutorial to remove it and change the logo to Xfce's or Cinnamon's:
a.4) [OPTIONAL] Hide the Guest-Session from the list of available users listed at the login page:
If you prefer to hide the guest-session from the list of available users at login page and NOT to boot straight to this temporary guest-session, use the command:
sudo gedit /etc/lightdm/lightdm.conf.d/50-my-config.conf
and edit the document to:
user-session=xfce [or 'cinnamon' or 'mate' as the case may be]
This is handy in case you want to quickly change its settings (for example, before a party on your house or the arrival of a guest, set 'autologin-guest' and 'allow-guest' to 'true' to enforce a default login to the temp guest-session account).
b) Make the umask of '002' stick forever:
On a terminal run the following commands:
b.1) to modify login.defs:
sudo gedit /etc/login.defs
and modify the value of the line beginning by UMASK to '002';
double-check if the value of USERGROUPS_ENAB is set to 'yes';
save the file and exit.
b.2) to modify pam.d:
sudo gedit /etc/pam.d/common-session
and modify the following statement:
session optional pam_umask.so
session optional pam_umask.so umask=002
b.3) to create a user's umask script:
gksu gedit /etc/profile.d/umask.sh
on this new empty document add the following argument,
being careful that there are NO empty spaces before 'umask'
and that there are THREE zeros before the digit '2':
Reboot after you finish this step.
STEP 02: Create a new common group and the new users who will use the shared folder
Use the graphical tool from your edition (in Xfce it is called 'Users and Groups') to create a new group that will be used by all users who will use the shared folder. Also create all the new users you require and add each one of them to the newly created 'group'.
WARNING: 'Users and Groups' is itself buggy, allowing you to create a 'username' with an underline sign on the user's name. When a new 'user' is created, the system also creates a new 'group' with that very same name (with the only member of this 'group' being the new 'user' himself). However, it is AGAINST the Linux/UNIX rules to have an underline on any group's name! So, if you create a user called 'User_1', you may end up having a LOT of problems due to regressions caused by the presence of a group ('User_1') with an underline on its name.
ADVICE: it is also a good idea to add your own username to EACH user's group and to add a 'reminder' file on your own 'home' directory (and if your 'home' is not encrypted, also protect it from prying eyes by modifying the permissions of this reminder file after you have saved it to 400, thus ensuring that YOU can read it but also mandating that even you must log as root to modify it while at the same time disallowing anyone else to read the contents of this file) with the passwords assigned to each family user so that in an emergency you can access anyone's home folder (even if it is encrypted) and access all the folders and files of anyone in order to be able to correct some foolishness lay users are prone to do every now and then. But please be a gentleman and tell your family members about this backdoor to their accounts, OK?
On the end of this step you should have (a) a new group, (b) new users and (c) all new users belonging to this new group. For example and supposing your username is 'sysadmin' and the new group is called 'commonshare', you must have in the end of this step something like this:
USER NAME >> BELONGS TO GROUPS >>> USER UMASK
sysadmin >> sysadmin, user2, user3, user4, user5, commonshare >>> 002
user2 >> user2, commonshare >>> 002
user3 >> user3, commonshare >>> 002
user4 >> user4, commonshare >>> 002
user5 >> user5, commonshare >>> 002
Do NOT go to the next step until you got this one right!!!
STEP 03: Update your system
Now it is time to update your new installation (use your 'Update Manager') and reboot afterwards.
STEP 04: Create the folders you going to need
Supposing the name of the shared folder will be 'Shared' and that it will be located on the partition '/media/Data_1' and that the shared group you created is named 'commonshare', use the following commands:
a) to create the shared folder
b) to let the group take ownership of the newly created shared folder
sudo chown -R :commonshare /media/Data_1/Shared/
c) to create a temporary "receiver" folder
After you create the "receiver" folder, copy to it all the subfolders and files you want to share (for example your movies, mags, presentations, documents, ebooks, music files, databases, etc).
STEP 05: Set the setgid of the shared folder to '2' and change the mode of the "receiver" folder and (temporarily) also of all its subfolders and all files you imported to '777'
Use the following commands to:
a) set a setgid of '2' for the shared folder
chmod 2777 /media/Data_1/Shared/
b) change the mode of the copied subfolders and files to 2777
chmod -Rv 2777 /media/Data_1/Temp_Chmod_2777/
STEP 06: Copy the contents of the temporary "receiver" folder to the shared folder to set the permissions right of the subfolders and files of the shared folder
Use the following command:
cp -Rv /media/Data_1/Temp_Chmod_2777/ /media/Data_1/Shared/
I know it looks silly to copy a bunch of subfolders and files first to one location, change its permissions and then copy them all to a second location but that is due to a buggy 'chmod': if you were to change the mode of any subfolders and its files anywhere to 2664, you would notice that ALL your subfolders "disappeared" (even to any graphical file manager installed) and if you were to check the permissions of the visible main folder with for example Thunar, it would tell you something about the permissions of the folders being "inconsistent" and if you were to leave them as 2777 (without copying them "again" to the shared folder), it would leave you exposed, with all 'others' users being able to execute any program or script per change present in any of those subfolders.
The operation then looks pretty weird when you compare the permissions of the subfolders and files of the "receiver" folder (which you set to 2777 on step 05.b above) with the permissions of the subfolders and files you just copied into the shared folder: Surprise ! Surprise !! Surprise !!! Those permissions are all 2664 instead of the 2777 you would otherwise have expected it to be! The reason is again a "bug" or as on this case, an "historical bad choice" from the Unix time: AFAIK there is NO way to copy a bunch of files to someplace in any Linux system and have those copied files conserve their "execute" permission of the original files '777' permissions (with the change of the last '7', happening because of the umask you set to '002', being the easiest to understand the reason of the change), even to a folder where you set its setgid to '2' (therefore forcing all preexistent subfolders and files to take the same group permissions of the parent folder, as well as also forcing those permissions to any subfolder and/or file anyone creates or modifies after the setgid was set to that folder) but, in the end of this last step the permissions of ALL subfolders will be 777 (as it should be) and because of this "historical choice" of the copy process, the permissions of ALL files will be 664 (as it should be) and with those permissions being inherited by any file and any subfolder any user modifies or creates.
So, after this last step, your shared folder is ready to be used, viewed and modified by any of the members of the group while still allowing the files to be viewed by any 'others' users of the computer, remote or local.
P.S.: permission is GRANTED for you to quote in part or in full this "how-to" tutorial anywhere you want but please be a gentleman and also quote the source, OK?
My Personal Motto:
"I do not use Linux because it is free; I am free because I use Linux".
My Girlfriend's Motto:
"Let's work together to make windows means only something we look through,
gates only something we pass through and bill only a synomyn of the greatest pirate of them all!"
My Favourite Phrase of the first decade of 21st Century:
"Son! stop being a bill and quit downloading those torrent movies of yours, right now!"
[heard it in a suburb of Seattle, WA, no more than 10 miles from Microsoft HQ, of all places!]
since Mint in general, no matter which release, is a typical workstation OS
- this is not a good How2 for the Mint users;
it contains too many risks and also disable the mdm is not in sense or meant
(but still respect and appreciate your knowledge about UNIX ;-) )
There is a reason for specific server editions
and other reasons
for a workstation OS.
In your case you can adjust your ws OS like you did above
or you grade up, since you have to deal with the data volumes as per
your description above...
agreed with Hammer459.
@Mike_in_Brazil if you have that much shared files, both in numbers and size, it is wise to set up a NAS for several reasons.
First and foremost for recovery reasons. If you have issues with the inboard disk or any other issues with your computer your data is less likelly to be lost.
Second you can then share data over more computers, should that be required.
Third a NAS will nicely handle access rights properly over NFS.
As for my suggested simple solution replace 'a+rw' with 'g+rw' if you so wish. Or any other appropriate access rights combo.
@Mike_in_Brazil: I just said that the complexity involved to make your solution work (which you certainly need in your setup) clearly demonstrates that this is the way it wasn’t intended to go. The more so that it needs a specific installation, hence it cannot be called a general-purpose desktop workstation anymore.
And yes, Ubuntu has more than one design flaw ;-)
Hi, Magic Mint,
your comment shows you forgot that Ubuntu behaves EXACTLY the way I propose Mint to behave(and Ubuntu's umask is, by default, '002'). So, does it means you think Ubuntu has a design flaw???
Shared Folders are, by definition, HUGE (the one I share with my family members is 750 GB and with about a million files). Thus, the "simple way" you suggest does not work because: (a) each 'chmod' command would take a LOOOOOOOONG time to run (in my case about 18 hours to check and change the mode of all files of my shared folder!) and so, if applied, your method would keep almost any computer in an endless loop, with 'chmod' writing and writing again and again to the disk (effectively locking the user out of use of the computer); (b) the argument "a+rw" in your suggestion means you would be giving Read and Write permissions to ALL users, which, as noted on the body of this "how to", is UNWISE, to say the least.
In short: your method seems nice and "simple" but is NOT applicable in the real world. Sorry!
The complexity of the solution shows why the sharing of a commonly writable directory isn’t a good idea: it seems to have been willfully prevented by design ;-)
and another much more simple way, too.
this shows very well, where we are today in 2015;
thanks to the devs, because we can do the same with some mouse-clicks
nowadays - just need to know which tools, GUI included, to use.
This how2 shows how UNIX tastes...
and so promoted ;-)
A simpler way to solve your problem... Create a root cronjob that every 5 minutes or some such recursively changes file permissions in that shared directory 'chmod -R a+rw /opt/sharedfiles'