I'm using a Pi4 as a file server. Everything was fine - USB drives are mounted, Samba shares makes them available to the network. No issues until I reformatted the drives as ext4. I moved the data, mounted the drives and set up samba again. The drives show up, but they are read only. My Linux Mint machine tells me that root is the owner. Windows gives an error message. I suspect I'm missing something obvious. I have tried setting the owner and the permissions on the drives. They all look good on the Pi, but they don't carry over to the Samba share.

More specifics: On the Pi, the drives are mounted in fstab as follows:

#Local Disks  
UUID=27705094-8dd5-4f2f-a854-576cfb011f76 /mnt/5tb3 ext4 defaults 0 0  
UUID=f1029e86-3e6c-497e-bdeb-3672941db372 /mnt/5tb2 ext4 defaults 0 0  
UUID=44ba2a5d-e984-4716-b8dd-0d99e6c92489 /mnt/5tb1 ext4 defaults 0 0  
UUID=e2550d94-ec3b-46ab-8b78-e9ef30a81c07 /mnt/2tb ext4 defaults

The samba shares are all set up the same

    comment = 5tb1  
    path = /mnt/5tb1  
    browseable = yes  
    writeable = yes  
    only guest = no  
    create mask = 0777  
    directory mask = 0777  
    public = yes  
    guest ok = yes

Then they are mounted on my dual boot Windows/Mint laptop in fstab

#Network Drives  
//raspberrypi/5tb1  /mnt/5tb1  cifs  x-systemd.automount,username=user,password=pass 0 0  
//raspberrypi/5tb2  /mnt/5tb2  cifs  x-systemd.automount,username=user,password=pass 0 0  

I think the permissions on the drives look good from the Pi:

mot@raspberrypi:~ $ ls -al /mnt  
total 32  
drwxr-xr-x  8 root    root  4096 Oct  2 11:08 .  
drwxr-xr-x 18 root    root  4096 May  2 20:36 ..  
drwxrwxrwx  7 mycroft users 4096 Oct 12 20:08 2tb  
drwxrwxrwx  5 mycroft users 4096 Oct 10 19:20 5tb1  
drwxrwxrwx  6 mycroft users 4096 Oct  5 12:05 5tb2  
drwxrwxrwx  7 mycroft users 4096 Oct 10 19:40 5tb3  
drwxrwxrwx  3 mycroft users 4096 Oct  2 11:08 Laurie  
drwxrwxrwx  3 mycroft users 4096 Oct  2 11:08 yogalaptop  
mot@raspberrypi:~ $   

But from my Mint machine, root is the owner, and I can't change the permissions. enter image description here

In Windows, I can map the drive, but it comes up as read only.

Thanks for looking at all this. If you have any ideas, let me know. I'm sure it's soemthing simple. This can't be as hard as it seems right now!


The old fstab entry was:

UUID=1062310A6230F5D6 /mnt/5tb1 ntfs uid=user,gid=group 0 0 

and the new one is:

UUID=44ba2a5d-e984-4716-b8dd-0d99e6c92489 /mnt/5tb1 ext4 defaults 0 0
  • This appears to be a problem with Linux Mint... why are you asking about Linux Mint here in RPi SE?
    – Seamus
    Oct 13, 2023 at 17:01
  • Actually, I don't think it's a Mint issue because I have the same problem in both Mint and Windows. Thanks for the thought!
    – TMSpack
    Oct 13, 2023 at 20:54
  • Well, actually... being common to Mint and Windows does not change the appearance. I understand that RPi is the file server, but simply re-formatting to ext4 would not cause the problem you describe.
    – Seamus
    Oct 13, 2023 at 21:55
  • Good point, Seamus - I didn't think re-formatting to ext4 would cause problems either, but the problem is there. Re-mounting the drives did require mounting it with different parameters. The old fstab entry was UUID=1062310A6230F5D6 /mnt/5tb1 ntfs uid=user,gid=group 0 0 and the new one is UUID=44ba2a5d-e984-4716-b8dd-0d99e6c92489 /mnt/5tb1 ext4 defaults 0 0. I tried force user = user and force group = group, with no luck. Is there some other parameter I am missing?
    – TMSpack
    Oct 14, 2023 at 16:06
  • Coupla' things: First on the format for Comments: When you're addressing a comment to a specific user - one who is not the author of the Q or A under which the comment appears - you should preface that comment with that specific user's handle; e.g. @seamus.
    – Seamus
    Oct 14, 2023 at 17:21

1 Answer 1


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
└─sda1      ext4   1.0   PASSPORT2TB 86645948-d127-4991-888c-a466b7722f05    1.5T    10% /mnt/Passport2TB
├─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
├─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...


  • 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:

  1. on your client (Mint), install sshfs
sudo apt update
sudo apt install sshfs
  1. set up a mountpoint on Mint:
sudo mkdir /mnt/rpi-sshfs  
  1. 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 (' 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.

  1. On the RPi server: Make sure that the samba server is installed:
$ which 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
  1. On the RPi server: Create a folder to share:
$ cd  
$ mkdir pishare  
$ chmod 0740 pishare  
  1. On the RPi server: Create samba users
$ sudo smbpasswd -a pi
  1. 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:

path = /home/pi/pishare
read only = no
public = yes
writable = yes

  1. On the Mint client: Make sure that cifs-utils is installed

  2. On the Mint client: Create a mount point:

$ cd
$ mkdir mysharedpi
  1. 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:

  1. 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
  1. 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 :)

  2. 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.

  • Thanks again for all your help. The answer turned out to be in Section II-A Samba on my Mint machine. The uid and gid options allowed me to set the permissions for the drives properly.
    – TMSpack
    Oct 20, 2023 at 23:01
  • @TMSpack: That's great, glad it helped.
    – Seamus
    Oct 21, 2023 at 0:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.