Help with SMB mount - can read/delete but not write

Submitted ⁨⁨3⁩ ⁨weeks⁩ ago⁩ by ⁨user9314p@lemm.ee⁩ to ⁨selfhosted@lemmy.world⁩

Hi all, I’m so confused about what I’m doing wrong and couldn’t find any guides/troubleshooting for my specific problem, so hoping someone here can help.

I’m setting up a new Proxmox server and trying to share a folder between a “Fileserver” VM to a “Docker” VM via SMB/CIFS (both Ubuntu 24.04.1 LTS)

my smb.conf on the fileserver:

[pool]
     path=/mnt/mergerfs
     read only = no
     browsable = yes

my fstab entry on the docker VM:

//192.168.0.20/pool     /mnt/pool       cifs    _netdev,credentials=/etc/.smbcredentials,uid=1000,gid=1000      0       0

On the Docker VM, I can see that the folder is mounted properly with the correct permissions for the uid/gid specified (dockeruser) and with 755 permissions, but I am unable to write to it with either dockeruser or root. Interestingly, I am able to DELETE files on the share, which is confusing the hell out of me.

If I mount is as root (no uid/gid arguments in fstab), I am able to write to it, but for “best practices” I’d like to get it working with a non-root user. Any ideas?

source

Comments

Sort:hotnew top

erer@lemm.ee ⁨3⁩ ⁨weeks⁩ ago
First of all, docker is not a VM. And for your issue, don’t mount file shares like that in docker. Mount the file share on the host and then add it to the container as a volume. Again, a container is not a VM. It seems like you are trying to use a container like a VM. The only reason to mount a file share inside a container it’s if the app inside the container supports and can handle file shares by its own like nextcloud.

source
- user9314p@lemm.ee ⁨3⁩ ⁨weeks⁩ ago
  I guess I should have been more clear. My “Docker VM” is an Ubuntu VM (running on the same Proxmox host as my “File server” VM) that I will be using to deploy docker containers. I am trying to mount the SMB share on the Ubuntu VM and will pass that to the containers as a volume.
  
  source
  - erer@lemm.ee ⁨3⁩ ⁨weeks⁩ ago
    Oh ok, that makes more sense. Then just like the other person says, it’s most likely a user permission error. Is your dockeruser in the docker VM the same as in the other VM? As in the same uid and guid? This week I created a NFS share to mount for a container and I created a new user in both side with the same uid and guid
    
    source
NegativeLookBehind@lemmy.world ⁨3⁩ ⁨weeks⁩ ago
Additionally, have you tried the

writeable = yes

Option?

source
- user9314p@lemm.ee ⁨3⁩ ⁨weeks⁩ ago
  I’ve read that writeable = yes and read only = no are interchangeable and you don’t need one if you have the other, but I’ll try this when I get home and report back.
  
  source
just_another_person@lemmy.world ⁨3⁩ ⁨weeks⁩ ago
Two things:

This is the most inefficient way of sharing files between containers. Use the same volume mount between containers if you just want both to have access to the same files

In order for SMB to work properly, and not cause file access violations, you need to have unique users for auth that map to a UID on the filesystem. If the files and folders you’re mounting are owned by root with uid=0, and SMB maps to another user you’ve created with uid=1000, then your SMB user won’t be able to read or write anything.

It may be easier to explain exactly what you’re trying to achieve here so someone can offer a better way of setting this up for you.
source
- user9314p@lemm.ee ⁨3⁩ ⁨weeks⁩ ago
  Are you saying to mount the disks on the Proxmox host and share them with the containers? I’ve seen people prefer to keep the host “clean” and run something else like OMV in a VM to handle the file serving. I’m using Ubuntu instead mainly as a learning exercise, as I already have OMV installed on bare metal on my main server. I’m passing my SATA controller through to the file server VM and it’s going to be running mergerfs and Snapraid, and sharing the merged pool via samba.
  
  So I need to make sure there’s a user with uid/gid 1000 on the SMB host that has write access to the folder I’m sharing? I think this is already the case but I’ll double check.
  
  This is a 2nd server I’m building to back up data from my main NAS. The goal is to set up something like restic to back up my important pictures/documents/etc. Since the CPU on this also has Quicksync I’m planning to use it for Jellyfin and migrate my Radarr/Sonarr stack over.
  
  source
  - just_another_person@lemmy.world ⁨3⁩ ⁨weeks⁩ ago
    
    His is the most complex way of simply sharing files between containers I’ve ever heard. That sure sounds like bad advice to me. You have a link to that?
    
    All I’m saying is that if you’re sharing files between two containers, giving them both volumes and using the network to share those files is not the best practiced way of doing that. One volume, two containers, both mount the same volume and skip the network is the way to do that.
    
    Samba maps users in its own DB to users that exist on its host. If you’re running it in a container, it’s likely it’s just going to default to root with uid=1000. So if you start a brand new Samba server, you need a fresh user to get started, right? So you create a user called ‘johndoe’ with uid=1100 and give it a password. Now, that user is ONLY a samba user. It doesn’t get created as an OS user. So if your default OS user is ‘ubuntu’ with uid=1000, you’re going to have permissions issues between created files for these users because 1100 is not equal to 1000.
    
    To solve for this, you create user mapping in the samba configs that say “Hey, johndoe in samba is actually the ubuntu user on the OS”, and that’s how it solves for permissions. Here’s an example issue that is similar to yours to give you more context. You can start reading from there to solve for your specific use-case.
    
    If you choose NOT to fix the user mapping, you’re going to have to keep going back to this volume and chown’ing all the files and folders to make sure whichever user you’re connecting with via samba can actually read/write files.
    
    source
    -> View More Comments
Appoxo@lemmy.dbzer0.com ⁨3⁩ ⁨weeks⁩ ago
Maybe take a look at your smb share config?
Sounds like something that are considered “Special” permissions on Windows that allow you to do only some actions but not all (way beyond read/write/execute)
Maybe also take a look if there are ACLs active?

source