Your Q omits some details, but I feel that part of the problem is in the /etc/fstab
entries - the ones in your RPi, and/or the ones in your Linux Mint machine. Let's approach the issues raised in your question in this order:
- the
fstab
in your RPi server
- the
fstab
in your Linux Mint client (if necessary)
- the
samba
config (if necessary)
Part I: The fstab
on your RPi server
Using the terminal on your RPi, do this:
$ lsblk --fs
Following is the output on my system:
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
└─sda1 ext4 1.0 PASSPORT2TB 86645948-d127-4991-888c-a466b7722f05 1.5T 10% /mnt/Passport2TB
sdb
├─sdb1 vfat FAT16 6969-16D1 205.9M 19% /mnt/sdpi/boot
└─sdb2 ext4 1.0 f6ea6ef9-68be-479d-b447-5f76391cc02f 22.9G 17% /mnt/sdpi/root
mmcblk0
├─mmcblk0p1 vfat FAT32 bootfs CEE7-0DF0 203.6M 20% /boot
└─mmcblk0p2 ext4 1.0 rootfs ebadab55-bd70-46a9-8f18-995c136fb5b2 54.1G 3% /
- See the notes below on the
lsblk --fs
commandNote 1.
Let's take a look at the entry in the RPi's /etc/fstab
that produced the output from lsblk --fs
above:
# Add the PASSPORT2TB mount
LABEL=PASSPORT2TB /mnt/Passport2TB ext4 rw,user,nofail 0 0
- Note that in this entry, the
LABEL
is used as identification instead of the UUID
. Use of LABEL
instead of UUID
is criticized by some because it's not Unique, but for small-ish personal networks without hundreds of devices, using a unique LABEL
is common sense.
As with most things, it's always good practice to consult the system manuals before going off half-cocked, or on the basis of some blog that may have been posted by a half-wit. In this case, on RPi, from the terminal, do this to see the local manual for fstab
:
$ man fstab
The manual
identifies each of the six (6) fields used in an fstab
entry, and tells us that their order is important. If the RPi is the server of this partition for other systems on your network, this is all you need.Note 2 fstab
entries for other systems (client systems) can be more complex...
However...
- I'm a bit suspicious of the use of the
defaults
option in your fstab
entry. Why? Partly because all default values are not explained fully in man fstab
, and partly because of the Debian factor (Debian has been known to change things in their distro - and therefore the RPi OS distro). To keep things straight, suggest you use rw,user,nofail
in the fourth field just for now - instead of defaults
.
Part II: the fstab
in your Linux Mint/Windows client (if necessary)
Part II-A: Samba
Your Mint client fstab
entries to the RPi server's Samba shares appear to be reasonable (although the noauto
option is typically used). However, Mint configuration is a wee bit off-topic here, and since you're reporting issues, it seems a good idea to limit the variables. Consequently, I'll suggest the following changes to your Mint client fstab
entries which try to avoid potential complications brought in by the use of systemd
(systemd.mount
). Since you are mounting a Samba share (cifs
), you should refer to man mount.cifs
as the source for options used in /etc/fstab
.
//raspberrypi/5tb1 /mnt/5tb1 cifs rw,nofail,username=user,password=pass,vers=3,uid=pi,gid=pi,file_mode=0644 0 0
You should also verify that cifs-utils
is installed on the Mint client.
Part II-B: sshfs - a recommended alternative to Samba:
For Linux-to-Linux filesharing (and even on Windows, according to this source), I'll suggest you take a look at sshfs
as an alternative to Samba. It's simpler, more consistent and more secure. Here's how:
- on your client (Mint), install
sshfs
sudo apt update
sudo apt install sshfs
- set up a mountpoint on Mint:
sudo mkdir /mnt/rpi-sshfs
- connect to your RPi server from Mint:
$ sudo sshfs -o allow_other,default_permissions pi@raspberrypi:/mnt/Passport2TB /mnt/rpi-sshfs
The authenticity of host 'raspberrypi (192.168.1.144)' can't be established.
ECDSA key fingerprint is SHA256:hrj8Y9wQ4IUjAINAY9uwicdqQJwhRAHg4TwDBZhKw6g.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
pi@raspberrypi4b's password:
This example (above) shows a manual sshfs
mount using passwords. The same mount can be made at startup using the /etc/fstab
file if you have generated a public-private key pair using ssh-keygen
(see the tutorials listed below for details).
There are several tutorials and how-tos available on sshfs
for the cost of an Internet search. Here's one from Baeldung, another one and this one.
For the Mint client, once you've read the tutorial(s), the following /etc/fstab
entry should get you started; it uses the systemd.automount
featuresNote 2 mentioned above:
pi@raspberrypi:/mnt/Passport2TB /mnt/rpi-sshfs fuse.sshfs noauto,x-systemd.automount,_netdev,reconnect,identityfile=~/.ssh/id_rsa,allow_other,default_permissions 0 0
The identityfile
is a ponter to the local (Mint) SSH key file so that the mount can take place without password prompts.
Part III: the samba config (if necessary)
This (Part III) is structured differently from Parts I and II. It is based on a simple, contrived example instead of the values in the OP's Question. Part of the reason for this difference is that I wanted to follow the official Samba/CIFS documentation for Raspberry Pi as much as possible. And so, Part III is set up as a stand-alone example; simple, but hopefully detailed enough to illustrate the key concepts.
- On the RPi server: Make sure that the
samba
server is installed:
$ which samba
/usr/sbin/samba
$ samba --version
Version 4.13.13-Debian
#
# if either of the above responses from your RPi fail to match these, then proceed w/ following:
#
$ sudo apt update && sudo apt install samba samba-common-bin
- On the RPi server: Create a folder to share:
$ cd
$ mkdir pishare
$ chmod 0740 pishare
- On the RPi server: Create samba users
$ sudo smbpasswd -a pi
- On the RPi server: Configure
/etc/samba/smb.conf
on your RPi server; edit file to add the following to the end of the file, and then run sudo service smbd restart
to load the new config file. Also note, the share name is whatever you put inside the brackets; i.e. [pishare]
- or [something_else]
if you prefer. Please note that the share name ([pishare]
) has nothing to do with the path
setting:
[pishare]
path = /home/pi/pishare
read only = no
public = yes
writable = yes
On the Mint client: Make sure that cifs-utils
is installed
On the Mint client: Create a mount point:
$ cd
$ mkdir mysharedpi
- On the Mint client: You should now be able to connect from your Mint client to the folder
~/pishare
on the RPi server. Verify this first with a manual (command line) mount
:
$ sudo mount -t cifs -o user=pi,vers=3.1.1 //raspberrypi/pishare /home/pi/mysharedpi
#
# unmount the share when you've finished with it:
#
$ sudo umount mysharedpi
Permissions of any files in /home/pi/mysharedpi
may be screwed up, but not to worry; we'll fix that:
- On the Mint client: add a permanent mount in
/etc/fstab
$ sudo nano /etc/fstab
#
# add the following line:
//raspberrypi/pishare /home/pi/mysharedpi cifs rw,nofail,username=user,password=pass,vers=3,uid=pi,gid=pi,file_mode=0644 0 0
Verify the mount works. Afterwards, you can change directories (e.g. from /home/pi/sharedpi
to /mnt/somethingelse
), and explore other options. Suggestion: Make one change at a time :)
In conclusion, we've seen that samba
is more burdensome to set up and configure than sshfs
.
NotesNote #
Note 1:
Note the tree format, and the headings produced by lsblk --fs
. Under the NAME
column heading, we see the device name (sda
), and immediately underneath it & indented, the partition name (sda1
); i.e. the tree format. Other useful info for each partition is displayed under the various headings.
Examining the output for the partition sda1
, note that it is formatted as the ext4
file system (FSTYPE
). It has a user-assigned LABEL
. [sda1
also has a machine-assigned UUID
which is not shown here because of the chosen entry in /etc/fstab
- as explained below.] The final heading shows the MOUNTPOINT
- if it is mounted! In this case (sda1
) is mounted on the RPi at /mnt/Passport2TB
(where the Passport2TB
portion of the mountpoint was specified by an organized user :)
Note 2:
Sadly (or gladly, depending on your point of view), man fstab
may not be the final word on constructing /etc/fstab
. This due to the introduction of systemd
, and its underlings systemd.mount
, systemd.automount
, systemd-fstab-generator
into the mix. Ref man systemd.mount
.
ext4
would not cause the problem you describe.@seamus
.