I have several PCs located around this building. I would like to have access to the public folder on any machine from any machine. This is so I don’t have to use sneaker net anymore to take files from one machine to another. I only want the public folders available. I don’t want have to login with desktop sharing. All the machines are on the same router and have IP addresses like 10.0.0.2 etc etc. Is there an easy way to do this?
Thanks in advance for your help with this!
Pat (tablepc)
Since you are asking here, I guess all of these PCs have Fedora installed (or at least some Linux distro). In this case, the easiest way I can think of is using SSH/SFTP. Simply login with your credentials on another machine and access whatever folder you need to access.
Plain commandline SFTP is not particularly fun but you can use Dolphin/Nautilus with an ‘sftp://server/path/to/folder/’ address, Midnight Commander, or even a dedicated SFTP client.
Filezilla is a fantastic SFTP / FTP client.
One would have to open firewall ports, 22 for SFTP or 21 for FTP.
If one has sshd running, it should work with your username and password.
I’m not very experienced with this, so I’m gonna ask this:
Is the “storage” you want to access “from any PC”:
A) Connected to the router?
B) In a server which PCs share?
C) In a Personal Computer that’s on the network, no matter how?
That said, maybe this could partially help (maybe not, but I still believe it’ll help):
On Fedora, I am pretty sure that I never had to do this, the ‘ssh’ service was always enabled even in the ‘public’ firewall zone.
For me it seems even easier to use rsync to transfer the files. That uses the ssh protocol and has worked flawlessly for me for quite some time. No need to configure anything else in most cases.
I think this is ultimately a matter of personal preference and some other requirements that were not included in the OP. E.g., accessing/copying individual files, without knowing the name beforehand, may not be so easy with rsync but works great with some SFTP client or even just Dolphin/Nautilus. But if the goal is to copy the whole directory, then yes, rsync is the better approach. But in that case, something like Syncthing that keeps directories synchronized in the background may be an even better choice.
That’s why I suggested OpenSSH, it is already active on Fedora in the default installation without additional configuration like for Samba or NFS, and access to files is authenticated and thus secure.
Under GNOME, in Settings, you can activate sharing the contents of the Public folder by navigating to GNOME Settings → Sharing → File Sharing.
Additionally, for a solid syncing solution of specific folders between devices (not necessarily on the same network), I second the suggestion of Syncthing.
I added the Public folder in file sharing but I can’t see is on another PC. I tried selecting Network in Nautilus with ssh://10.0.0.4 and I got the message “connection refused by server”. What’s my next step?
Thanks in advance for your help on this.
Pat (tablepc)
I believe you are mixing up two things. I recommended going the SFTP route because it is already active on any Fedora installation and doesn’t require any additional configuration (and especially not in Gnome or any other DE). Just use Nautilus and navigate to sftp://username@10.0.0.4 and it should just work™. (You can benefit from some additional configuration, e.g., I have a keypair with the private key in my SSH agent and the public key listed in .ssh/authorized_keys. This way, I can authenticate without having to type my password for the remote system.)
@tqcharm recommended Gnome’s integrated file sharing, which I think uses Samba, so the URL would have to be smb://10.0.0.4. But I have never used that, so somebody else will have to step in here. (I run a dedicated Samba server on my NAS and certain directories are automatically synced between the NAS and my clients with Syncthing.)
When setting up the file sharing in GNOME Settings, there is also File Sharing Access information presented, in the form of dav://your-pc-name. That should be the base address for accessing the shared folder. However, if it’s properly set up (e.g. same local network) then if you go to the other PC where you want to access the first one from, in Files (Nautilus), in the left sidebar, selecting Network, the shared folder of the other PC should be displayed[1]. The address shown is a longer one though than presented at the set-up stage, but that doesn’t matter, it should work by just double-clicking the linked shared folder.
Apparently, it uses davfs, based on the address output in the set-up stage.
Assuming, of course, that the PC is online on the same network. It might be needed that user is also logged on, I haven’t tested with the user which set up the sharing being logged out. ↩︎
follow instructions given by @tqcharm , that’s an easy, only-click solution without having to issue ssh certs, messing around with firewall, etc.
file sharing is well integrated in Gnome these days.
You don’t have to do any of that, the OpenSSH server is active, and the firewall allows access on port 22 by default. You can just log in with your existing username and password via SSH for a shell or access files via SFTP. There are absolutely no additional steps required (unlike the Gnome route, which needs to be configured on every system).
It is totally fine to disagree with me and to recommend other solutions, but please do not spread misinformation.
Not by default. The ssh client is active and can be used but the sshd service is disabled by default on a Workstation install.
It is necessary for the user to start the daemon with sudo systemctl enable -now sshd to enable and start the ssh daemon. It is also necessary to open port 22 in the firewall with either firewall-config (gui) or firewall-cmd (cli).
The client side does not require these actions, but the server side does when using workstation.
Interesting.
I was pretty sure that I did not have to enable sshd on my recent installs (and indeed, it was already enabled due to the way I install my systems, but that isn’t the case for Workstation or KDE edition, and I learned a few things when I investigated that).
I was only pretty sure, but not 100%. So before I made the claim, I checked the documentation regarding default services. From there, I could see in the linked files that 90-default.preset enables sshd and 80-workstation.preset doesn’t contain anything about sshd. Because these were the only relevant files linked in the documentation, I concluded that my memory was accurate and sshd was active by default. In particular, I did not take a look at the other preset files in the same directory (that’s going to be relevant in a moment).
After your response, I did spin up a new VM and installed Fedora workstation. And indeed, systemctl status sshd showed it as disabled. Hmmm …
Turns out that there is another preset file deployed by the workstation and KDE variants, 81-desktop.preset, which disables sshd and takes effect before 90-default.preset. And I don’t have this file on my installations, probably because I don’t install Workstation or KDE edition, I use the Everything installer, select the default “Fedora Custom Operating System”, and then add “KDE Desktop” in the additional software list on the right, which I think corresponds to ‘kde-desktop’, not ‘kde-desktop-environment’. After that, I use Ansible for the remaining system configuration, and with this workflow it works over SSH right away.
In any case, once I ran systemctl start sshd.service in this test VM, I could connect via SSH, without having to change the firewall config, which a quick check on the command line confirmed:
lars@fedora:~$ firewall-cmd --get-active-zones
FedoraWorkstation (default)
interfaces: enp1s0
lars@fedora:~$ firewall-cmd --zone=FedoraWorkstation --list-services
dhcpv6-client samba-client ssh
TL;DR: We were both right, it turns out you need to sudo systemctl enable --now sshd.service in the default Workstation and KDE installations. But that’s it, after that SSH and SFTP work, without changes to the firewall config, without additional changes to authentication, and without having to set up SSH certificates (that claim was what triggered my response, I have yet to see any setup of SSH with certificates, and in small to medium-sized contexts, regular SSH key pairs have always been sufficient for my needs).
I’m pretty sure one can enable root password and ssh access in the installer, even on ‘custom’ … so all depends on how one installs. So we’re all right 
Ah Linux, so many choices 
Yes, you can set a root password in the Everything installer, but that wasn’t the issue. I went on this goose chase because I wanted to know why my systems’ default services differed from what others wrote in this thread.
With “Fedora Custom Operating System” in the Everything installer, the preset file that disables sshd (81-desktop.preset) isn’t deployed, so sshd is enabled via 90-default.preset. And I don’t know of any other way to directly enable or disable services from the Anaconda GUI.
That’s the annoying part, the Workstation and KDE installers do something (disable SSH) that isn’t mentioned in the default services documentation.
IMO this is fine so for the Workstation (and Silverblue) installers, using GNOME as a DE. It’s only a matter of going to GNOME Settings → System → Secure Shell and enabling the option. GNOME will take care of enabling the background services.
And given there’s such an easy option to enable the service, I’d say it’s better not to be enabled by default.
That is because the workstation firewalld rules open port 22 by default along with all ports between 1025-65535
You left out the important part of my statement:
I am completely OK with SSH not being enabled on Workstation, a majority of users probably wouldn’t know what to do with it anyway.
What is annoying is that the documentation about that is incomplete. There is a documentation page that lists default services for “Fedora general”, “Fedora Server”, and “Fedora Workstation” (and “Fedora general (per-user)” but that isn’t relevant for this). This makes it appear that this information is complete when in fact it is not: there is also the 81-desktop.preset for Workstation and KDE, which disables sshd.service (and changes CUPS unit defaults) and which isn’t linked to on this page.