Sftp-mount as admin only gives read-access

Discuss
1

Discuss

I have a Raspberry Pi 5 running YunoHost with Nextcloud, Jellyfin, Vaultwarden and AdGuardHome.
In my home-network I am using it like a NAS from my workstation. For this I have created the keypairs and mounted the multimedia-folders in the fstab on my workstation.
It works like a charm. But what is bugging me is that I have to mount as root in order to be able to write in the yunohost.multimedia-folders. I think this is because, by default in YunoHost, the yunohost.multimedia-folder is owned my root.

My lines in the fstab look like this:

root@192.168.178.25:/home/yunohost.multimedia/share/Documents /home/clay/Dokumente fuse.sshfs _netdev,identityfile=/home/clay/.ssh/id_ed25519,allow_other,reconnect,x-systemd.automount 0 0

If I replace root with the yunohost-admin user in the fstab line, I only get read access. The same is true if I manually mount the folder with sftp.

2 questions:

  1. Are there security-risks to having root-owned keypairs and mounts on my workstation?
  2. If it is, is there a simple way to mount yunohost.multimedia as simple yunohost-user with write access?
2

Hi @clay,

1. Security risks of root-owned keypairs and mounts

Yes, there are some risks to consider:

  • Any file operation from your workstation runs with root privileges on the server
  • Accidental deletions or malicious scripts could affect system files
  • If your workstation gets compromised, the attacker has root SSH access to your server

For a home network, this is often acceptable, but not ideal for the long term.

2. Solution: Add your user to the multimedia group

The reason you only get read access is that write permissions on /home/yunohost.multimedia are controlled by the group multimedia, not by the root ownership.

From the YunoHost multimedia documentation:

“Une application ayant besoin d’un droit d’écriture sur les médias doit s’ajouter au groupe multimedia, car seul le groupe multimedia garde un droit d’écriture sur l’ensemble du dossier multimédia”
(An application needing write access must be added to the multimedia group, as only this group has write permission on the entire multimedia folder)

The fix is simple — SSH into your YunoHost server and run:

sudo usermod -a -G multimedia YUNOHOST_USERNAME

Replace YUNOHOST_USERNAME with the admin user you’re using in your fstab (the one that currently only has read access).

Then log out and log back in (or restart the SFTP session) for the group change to take effect.

After that, update your fstab to use your YunoHost user instead of root

This is also documented for SSH users in the yunohost.multimedia README:

“Pour ajouter ou supprimer simplement des fichiers multimédia via une connexion ssh, il peut être nécessaire d’ajouter l’user ssh au groupe multimédia.”

Hope this helps ! :wink:

1 Like
3

You can try NFS mounts instead of sftp

2 Likes
4

Problem solved. This was just perfect. Merci beaucoup ! I have never come across this documentation for multimedia, even though I have thoroughly read the YunoHost Docs.

1 Like
5

You’ve gotten me interested. What would be my advantage of using NFS instead of sftp?

6

I hope my follow up question is not lost at the end of this solved thread.

I mounted the shared multimedia folder with NFS just to see if there is a difference in performance.

But I’ve got the same problem: the folder is readable but not writable. I have used these options to share the folder yunohost.multimedia/share with NFSv4:

(rw,sync,no_root_squash,no_subtree_check)

Is there something to do with user rights or groups, too?

7

I am already using NFS for mounting backup here : Mount /home/yunohost.backup on a remote server - #6 by jarod5001

yunohost.multimedia/share should already have 775 as permissions. To fix this you need to mount using the correct uid and gid.

On your server check the id your_username

Use the correct id reported by the previous command in /etc/exports

/home/yunohost.multimedia your_laptop_ip(rw,sync,all_squash,anonuid=12345,anongid=12345)

Change 12345 with the correct id. Apply the changes et retry.

1 Like
8

Thank you! I had seen your post about NFS and had taken some information from it.

It still have no write acces in the multimedia folders when accessing from my client.

This is what I set up:

On the server:

$ ls -ld /home/yunohost.multimedia/share
drwxrwxr-x+ 8 server_admin server_admin 4096 Jan 31 12:50 /home/yunohost.multimedia/share
drwxrwxr-x+ 8 server_admin server_admin 4096 Jan 31 12:50 /nfsv4/yunohost.multimedia.share

This is my line in the /etc/fstab on the server:

/home/yunohost.multimedia/share /nfsv4/yunohost.multimedia.share  none  bind  0 0

This is my entry in /etc/exports on the server:

/nfsv4   192.168.178.0/24(rw,sync,all_squash,no_subtree_check,anonuid=19110,anongid=19110,fsid=0)
/nfsv4/yunohost.multimedia.share  192.168.178.48(rw,sync,all_squash,no_subtree_check,anonuid=19110,anongid=19110)

This is what sudo exportfs -v gives me:

/nfsv4/yunohost.multimedia.share
		192.168.178.48(sync,wdelay,hide,no_subtree_check,anonuid=19110,anongid=19110,sec=sys,rw,secure,root_squash,all_squash)
/nfsv4        	192.168.178.0/24(sync,wdelay,hide,no_subtree_check,fsid=0,anonuid=19110,anongid=19110,sec=sys,rw,secure,root_squash,all_squash)

The id-check on the server gives this:

$ id server_admin 
uid=19110(server_admin) gid=19110(server_admin) groups=19110(server_admin),1003(multimedia),4001(admins),4002(all_users),5001(mail.main),88820(fail2ban-web.main),37531(nextcloud.api),31261(nextcloud.main),70273(roundcube.main),20715(vaultwarden.admin),62347(vaultwarden.main),99558(jellyfin.admin),75880(jellyfin.main),32168(adguardhome.main)

On the client I do the mount like this:

$ sudo mount -t nfs -o nfsvers=4 192.168.178.25:/yunohost.multimedia.share /home/client_user/NFS-test

The mount is successful and the mapping seems to work too. I can write into the share folder but not in the multimedia-folders in it:

$ touch /home/client_user/NFS-test/test.txt
$ ls -l /home/client_user/NFS-test/test.txt 
-rw-rw-r--+ 1 19110 19110 0 Jan 31 13:38 /home/client_user/NFS-test/test.txt
$ touch /home/client_user/NFS-test/Documents/test.txt
touch: '/home/client_user/NFS-test/Documents/test.txt' kann nicht berĂĽhrt werden: Keine Berechtigung

When I do the same on the server as the same user, it works.

$ touch /nfsv4/yunohost.multimedia.share/Documents/test.txt
$ ls -l /nfsv4/yunohost.multimedia.share/Documents/test.txt
-rw-rw-r--+ 1 server_admin server_admin 0 Jan 31 14:18 /nfsv4/yunohost.multimedia.share/Documents/test.txt

This is quite a mystery to me…

9

192.168.178.0/24 is not your pc ip.

Are you mounting an external storage on multimedia folder ? Just use the external storage as NFS share

1 Like
10

192.168.178.0/24 is the IP range of my LAN as I might want to share a folder to another computer if I get it to work. I replaced it with 192.168.178.48 to see if that changed anything but it didn’t.

I have no external mounts on the server. Everything is right on the SSD.

Does NFS need some user rights, if that even exists? Like be added to group multimedia like nextcloud?