Linux share home directory

How do I share a folder with another Linux machine on the same home network?

I’m trying to share a folder on one Ubuntu machine with another Ubuntu machine on the same home network. When I right click on the folder and choose Sharing Options, it tells me I need to install Windows network sharing services in order to share folders. What does Windows have to do with this? I’m not trying to share with a Windows machine.

9 Answers 9

What does Windows have to do with this? I’m not trying to share with a Windows machine.

You’re right, this can be confusing. So let me try to clarify the terms first of all:

The way Windows shares files and printers is called SMB. The people from the SAMBA project have implemented all of Microsoft’s protocols and specifications for Linux. Ubuntu therefore supports the same sort of file sharing as Windows, which is called Samba.

• You can use SAMBA to share files between Linux machines. In fact, you might prefer it in case you have, for example, have a friend over with their Windows computer.
• Alternatively, you can use The Linux Way of sharing files, which is NFS (Network File System) — This answer to a previous question explains how to do it. (but it’s rather technical)

So, when the Sharing Options dialogue asks you to install the packages, you’re not actually installing any Microsoft software or anything like that. Go ahead and do it, it’s perfectly safe.

You can try to just enable sharing before you follow Salih Emin’s instructions; if it doesn’t work, you will get a simple warning, you can then do the steps Salih describes if needed. I have tried it on a freshly installed and up-to-date system, and I indeed needed to do this.

Thanks for the explanation. Funny that I’m trying to get away from Microsoft, and it turns out that even Linux uses pieces of their work. Ugh.

Well, the samba people have implemented Microsoft’s protocols much better than Microsoft themselves. Some solace there 🙂

I find SSHFS to be native, stable and extremely fast. I have two xubuntu machines (18.04) sharing /home folders and an Intel NUC as ‘dropbox’ USB stick. All over sshfs.

UPDATE 2020-07-12: I found SSHFS for Windows. A clean beautiful GUI, zero config and works with the SSH keys from linux-machines.

Here’s how to set this up sshfs and automatically reconnecting after a reboot using fstab without having to provide a password. A big thank you to serverfault user kubanczyk for how to reconnect after a remote suspend/resume.

I’ll use «Local machine — surfbox» for computer you’re connecting from, and «Remote machine — devbox» for the computer you’re connecting to.

Check your userID och groupID, they should both be 1000.

GroupID: id -g localuser UserID: id -u localuser

1. Get IP-adresses of your Local & Remote Machines.

I’ll use 192.168.1.150 for Local Machine (‘surfbox’) and 192.168.1.151 for Remote Machine (‘devbox’)

2. Install packages on Local and Remote Machines

sudo apt install sshfs fuse ssh 

3. Create a group fuse and add localuser to it

Create group: sudo groupadd fuse

Add localuser to the group: sudo usermod -a -G fuse $USER

4. Enable «allow_other» in fuse config

We will need this option when mounting in fstab

Edit /etc/fuse.conf with your command line editor. Remove the hashtag before user_allow_other and save.

5. Generate SSH keys on Local Machine

Do not provide a password when prompted. Just press Enter to leave blank.

ssh-keygen -t rsa -C youremail@example.com

Keys are stored in Local machine home directory /.ssh folder

6. Transfer your Local machine public SSH key to the Remote machine

ssh-copy-id -i ~/.ssh/id_rsa.pub remoteuser@192.168.1.151

You will be prompted for password for Remote user on Remote machine. Local machine public key is now added to the file ~/.ssh/authorized_keys on Remote machine.

7. Create a directory on Local machine /mnt folder where you will mount the Remote machine /home folder.

Choose any name which makes sense for your Remote machine.

8. Mount the Remote machine /home directory from terminal

sshfs [user@]host:[directory] mountpoint [options]

sudo sshfs [remoteuser]@192.168.1.151:/home/[remoteuser] /mnt/devboxhome -o allow_other,default_permissions -o identityfile=/home/[localuser]/.ssh/id_rsa

example: assuming «steve» is the username on both Local and Remote machines

sudo sshfs steve@192.168.1.151:/home/steve /mnt/devboxhome -o allow_other,default_permissions -o identityfile=/home/steve/.ssh/id_rsa

Since you have transferred the public RSA key to Remote machine you should not be prompted for remoteuser password.

You will get a warning that the machine is not trusted and prompted if it should be added. Add the Remote machine as trusted.

9. Verify: Browse Remote Machine /home directory

In terminal on Local machine you can now list Remote machine /home directory under /mnt/devboxhome

or use Nautilus to browse the directory. Great.

10. Enable reconnect after reboot

We will add an entry in /etc/fstab to make this happen. You will need your Local machine userid och groupid — see intro if you missed this. Edit /etc/fstab with your command line editor and add these two lines at the end of /etc/fstab

# Mount devbox at boot remoteuser@192.168.1.151:/home/[remoteuser]/ /mnt/devboxhome fuse.sshfs default_permissions,user,delay_connect,reconnect,ServerAliveInterval=15,ServerAliveCountmax=3,allow_other,identityfile=/home/[localuser]/.ssh/id_rsa,idmap=user,uid=1000,gid=1000 0 0

• delay_connect makes the kernel wait until the network is up until it tries to mount the directory on Remote machine.
• Since we are running as root during boot we have to specify the keyfile which is stored in localuser home directory.
• allow_other — users other than the one doing the actual mounting can access the mounted filesystem.
• idmap=user — only translate UID of connecting user
• reconnect, ServerAliveInterval, ServerAliveCountMax — ssh sends keep-alive pings. If ServerAliveCountMax consecutive pings fail, reconnect.

A user logging in as steve on Local and Remote machines would have:

steve@192.168.1.151:/home/steve/ /mnt/devboxhome fuse.sshfs default_permissions,user,delay_connect,reconnect,ServerAliveInterval=15,ServerAliveCountmax=3,allow_other,identityfile=/home/steve/.ssh/id_rsa,idmap=user,uid=1000,gid=1000 0 0

IMPORTANT: a slash after remote directory: steve@192.168.1.151:/home/steve/

11. Reboot

You should now be able to access Remote machine /home directory in the Local machine /mnt/devboxhome In Nautilus you can drag this folder to the Places bar

12. Repeat

Go through the same steps again on Remote machine to make the /home directory of Local machine shared.

Источник

How can I share a directory with an another user?

I don’t want the shared folder to be accessible by anyone on the system, I want it to be accessible just to a restricted set of users. How to I do that?

1 Answer 1

Taken from this excellent post on Ubuntu Forums by Morbius1.

The classic Linux way of doing this sort of thing goes something like this:

sudo chown :newgroup /home/Shared 

sudo adduser user1 newgroup 

Now you have some decisions to make about what you want those users to be able to do:

[a] All group users can add to and delete from the folder and can read and but not write to each others files:

sudo chmod 0770 /home/Shared 

sudo chmod 1770 /home/Shared 

sudo chmod 2770 /home/Shared 

sudo chmod 3770 /home/Shared 

A 1 in the first position of the chmod command is the sticky bit which prevents deletion of a file to anyone other than the owner.

A 2 in the first position of the chmod command is the setgid bit which forces all new or copied files to have the group of that folder.

A 3 in the first position of the chmod command is the combination of the sticky ( 1 ) & setgid ( +2 ) bits.

There is one caveat to all this as far as the setgid bit is concerned. All new files created in and any files copied to that folder will in fact inherit the group of the folder. But not files moved to that folder. Moved files retain the ownership from wherever they were moved from. One way to get past this problem is to use bindfs.

Finally if you want others outside the group to be able to see the files but not change them change the final 0 in the chmod command to a 5 eg:

sudo chmod 0775 /home/Shared 

Источник

Different linux distros sharing the same /home folder?

What is the best way to share the same /home directories between different linux distribution? I mean, I want to have both, say, Fedora and Arch, and I want to find my files at home no matter which linux distro I boot into. But if I mount the same partition for /home then I may mess up the configurations saved inside /home directory. So what can I do?

I am sharing my home folder between 3 linux distros. Here is one important issue with this that i have realised is probably inevitable. While it can be argued that accessing the same files with different versions of an application should not normally cause any data loss, it seems totally natural that various caches and search indices would need to be rebuilt each time you launch a different (major or minor) version of an application. It looks like i am experiencing this with GNOME desktop search index.

8 Answers 8

It certainly is possible to share a home folder (or partition) over different linux distributions.

But take the following notes:

• UID and GID must be the same on each distributions for the certain user(s).
• (as already pointed out) different configuration files for the same programs could result in unexpected behavior.
• If you install all distributions onto the same boot folder, make sure that the bootloader handles the different distributions correctly.

I have a working (virtual) setup:

/dev/sda (40GB) +-/dev/sda1 /boot (100MB, ext2) +-/dev/sda3 swap (2GB) +-/dev/sda4 /home (20GB, ext4) +---/dev/sda5 /root (Ubuntu 10.04, 5GB, ext4) +---/dev/sda6 /root (Fedora 14, 5GB, ext4) +---/dev/sda7 /root (openSUSE 11.3, 5GB, ext4) +---/dev/sda8 /root (ArchLinux 2010.05, 5GB, ext4) 

Ubuntu and Fedora both run Gnome 2.30, openSUSE has KDE4 and ArchLinux LXDE. All distributions have their necessary boot files on one partition. Switching between the distributions provides a persistent user configuration like intended.

The other possibility would be a lightweight home folder (doesn’t have to be a whole partition) for each of the distributions, only providing the necessary configuration files (.gnome2, .kde4, .compiz, .themes, etc.) and a shared data partition with the «heavy» stuff (documents, pictures, videos, music, etc.). Symbolic links in each of the distributions own home folder would then point to the shared partition.

Afterwards, this can be expanded at will to include other stuff as well.
Example: You have eclipse IDE installed on all distributions and want the same configuration and source files available everywhere. You can create symbolic links on each distributions home folder to the shared one to achieve this.

$ ls -l /home/user .eclipse -> /mnt/shared/.eclipse .gnome2 Documents -> /mnt/shared/Documents workspace -> /mnt/shared/workspace . 

$ ls -l /home/user .eclipse -> /mnt/shared/.eclipse .kde4 Documents -> /mnt/shared/Documents workspace -> /mnt/shared/workspace . 

If you’re not sure about interfering configuration files, try the second, safer way and find out which home components can be shared easily between the installed distributions.

Источник