I am not new to IpFire, but never used this feature.
It could be rather handy, saving the necessity of a second FTP server within the network, for example.
One box less, less noise, heat and power consumption.
However, I read that if the box is compromised, your data is gone.
I think that the ratio is that to get to your data on the LAN, first IpFire must be compromised, then your FTP must fail, so there are two steps. Is this correct?
So basically, if the data has little or no economical value, I assume one could risk to use the Extra HD feature.
Thanks for your comments!
A layered approach to defense always better.
For years I have been using the ExtraHD with the Samba addon and mapped the drive on a W10Pro and have never had a problem.
I have the ExtraHD unit formatted as EXT4, firstly inside the IPFire unit via Sata and today, via a 2.5 "USB3.0 box connected to a USB3 port and working perfectly.
Supposedly no one can install anything not certified by the IPFire development team as the system is fortified. As in everything, there can be problems, for example, that the 2.5 "HDD is physically damaged. Over time, they all fail. For that, see from time to time the S.M.A.R.T. features that IPFire offers.
As I mentioned, my experience is very positive in this regard.
I hope I’ve helped.
Regards and Happy New Year.
Thank you All for your interesting comments!
Best wishes for a New Year like … the good ol’ times!
Did you allow a specific user?
I see no way to add other users beyond Admin.
Ideally, I would like to restrict access to trusted users.
Hi again @gian.
I have Samba configured in this way:
And North Secure (Use whatever name you want) in this way:
[North Secure] path = /mnt/harddisk comment = Share - North Secure browseable = yes writeable = yes create mask = 0777 directory mask = 0777 force user = admin public = no
And the mount disk:
Hope this can help you.
Happy New Year!
I have setup a nfs share on one IpFire box, and I see it from an Ubuntu 20.04 guest:
showmount -e 192.168.17.1 Export list for 192.168.17.1: /mnt/harddisk/dati 192.168.0.0/24
The shared folder is 777 (don’t really like 777, but because I am fighting with permissions…). When I try to mount it, I get:
sudo mount -t nfs -vvvv 192.168.17.1:/mnt/harddisk/dati /home/gian/nfs mount.nfs: timeout set for Fri Jan 1 19:51:38 2021 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.17.1,clientaddr=192.168.21.139' mount.nfs: mount(2): Permission denied mount.nfs: access denied by server while mounting 192.168.17.1:/mnt/harddisk/dati
The client is on the other side of OpenVPN tunnel.
The NFS server is set with /etc/exports like:
Can’t really find out what’s wrong with NFS, however, I have no problem with Nautilus to open that folder using the IpFire root account such as:
But don’t like the approach of using root to access that folder…
Wouldn’t like to use Samba, because I only run Linux on my boxes…
well, the easiest thing I resorted to, is to use ssh.
I created a new-user, gave it ownership of /mnt/harddisk, and then connect to the share from Nautilus.
The new-user has no other privilege, so the firewall should be safe.
Maybe you could try this
On ipfire box (nfs server)
Create dir /srv/nfs/bck (bck as an example directory)
fstab add entry for additional drive mounted to /srv/nfs/bck
Blockquote UUID=xyzfromyourowndrive /srv/nfs/bck auto defaults 0 3
fstab add entry
Blockquote 192.168.1.1:/srv/nfs/bck /media/bck nfs rw,defaults,timeo=900,retrans=5,_netdev,x-systemd.automount,x-systemd.mount-timeout=30,rsize=1048576,wsize=1048576 0 0
Obviously reboot each systems after fstab modif.
If you ever need to rsync to that drive preserving your acl etc …,
Blockquote dd if=/dev/zero of=/media/bck/lou.image bs=(xsize) count=(ysize) status=progress
sudo mount -o loop /media/bck/xyzname.image /mnt
dd command is to map 0 to the size you require to rsync client
mke2fs is to format xyz image to the 0 space just created with dd
mount loop is to mount from client
Hope it help
Happy new year