Samba, share met full access

[StarWing]

"Ten lange leste.....":

Ik probeer al enkele dagen zonder succes een share op te zetten vanop een ubuntu machine, welke full access heeft voor iedereen, maar ik krijg het niet voor elkaar. Vele trial & error later kom ik er niet uit.

Opzet:
vm, ubuntu 22.04 met een "data-schijf" eraan. Deze schijf wil ik delen (mbv samba share) naar andere machines, zonder ww of passwoord (ja ik weet het, maar het is voor intern gebruik en de machines hangen niet rechtstreeks aan het internet)

Wat lukt er:
-ik kan de share benaderen en gebruiken vanop mijn windows machine.
-ik kan de share benaderen en bekijken vanop een andere ubuntu machine, echter kan ik geen bestanden/mappen maken zonder dat ik het "sudo" commando gebruik.
Wat de bedoeling is: vanop de andere ubuntu machines gebruik maken van deze share zonder "root", aangezien sommige services niet onder root draaien en bijgevolg geen toegang hebben tot deze share.

Achtergrond: wegens tijd teveel (revalidatie) ben momenteel mijn it infra aan het herstructureren, de bedoeling is van een aantal services (*arr, PiHole, Unifi, domoticz) op een docker server te zetten. De *Arrs hebben echter toegang nodig tot mijn "media" server (waar de share op staat)

Media server:
smb.conf

Code: Selecteer alles

[Media]
    comment = Emby Server
    path = /opt/media
    browsable = yes
    guest ok = yes
    read only = no
    writable = yes
    force user = nobody

Die force user is een laatste test, met of zonder maakt geen verschil.
Na iedere wijziging doe ik een reload van smb en herstart ik de andere vm van waarop ik de share wil benaderen, om zeker zonder overblijfsels te proberen.

share:

Code: Selecteer alles

vembyserver@vembyserver:/opt/media$ ls -l
total 32
drwxrwxr-x 5 nobody nogroup  4096 Dec  7 14:34 Audio
drwxrwxr-x 5 nobody nogroup  4096 Dec  5 09:25 downloads
drwxrwxr-x 2 nobody nogroup 16384 Jul 12  2022 lost+found
drwxrwxr-x 4 nobody nogroup  4096 Apr 23  2023 Video

Ik heb deze al meerdere malen ge-chownd ge-chmod, maar zonder success.
De parameters in de smb.conf heb ik ook al ettelijke malen aangepast (user / force user / force mask op dir en op file)
Maar ik denk eerlijk gezegd niet dat hier het probleem ligt, aangezien ik deze share perfect kan benaderen en gebruiken vanop mijn windows machine



Docker server:

Ik mount de share op de docker server:

Code: Selecteer alles

vdocker@vdockerserver:~$ sudo mount //192.168.10.150/Media/ /mnt/media -t cifs -o guest,rw

en dit geeft:

Code: Selecteer alles

vdocker@vdockerserver:/mnt$ ls -l
total 0
drwxr-xr-x 2 root root 0 Dec  7 13:24 media

Code: Selecteer alles

vdocker@vdockerserver:/mnt$ cd /mnt/media/
vdocker@vdockerserver:/mnt/media$ touch dd
touch: cannot touch 'dd': Permission denied
vdocker@vdockerserver:/mnt/media$

echter:

Code: Selecteer alles

vdocker@vdockerserver:/mnt/media$ sudo touch dd
touch: setting times of 'dd': Permission denied
vdocker@vdockerserver:/mnt/media$
vdocker@vdockerserver:/mnt/media$ ls -l
total 0
drwxr-xr-x 2 root root 0 Dec  7 13:34 Audio
-rwxr-xr-x 1 root root 0 Dec  7 13:59 dd
drwxr-xr-x 2 root root 0 Dec  5 08:25 downloads
drwxr-xr-x 2 root root 0 Jul 12  2022 lost+found
drwxr-xr-x 2 root root 0 Apr 23  2023 Video
vdocker@vdockerserver:/mnt/media$

De touch: setting times of 'dd': Permission denied is een nieuwe, die had ik nog niet gehad waarschijnlijk ergens iets anders verprutst/

Code: Selecteer alles

vdocker@vdockerserver:/mnt/media$ mkdir hallo
mkdir: cannot create directory ‘hallo’: Permission denied
vdocker@vdockerserver:/mnt/media$

Code: Selecteer alles

vdocker@vdockerserver:/mnt/media$ sudo mkdir hallo
vdocker@vdockerserver:/mnt/media$ ls -l
total 0
drwxr-xr-x 2 root root 0 Dec  7 13:34 Audio
-rwxr-xr-x 1 root root 0 Dec  7 13:59 dd
drwxr-xr-x 2 root root 0 Dec  5 08:25 downloads
drwxr-xr-x 2 root root 0 Dec  7 14:00 hallo
drwxr-xr-x 2 root root 0 Jul 12  2022 lost+found
drwxr-xr-x 2 root root 0 Apr 23  2023 Video
vdocker@vdockerserver:/mnt/media$

Wat in doe ik verkeerd ?
Als ik bv een Transmission (zonder docker) opzet werkt dit niet, omdat Transmission onder zijn eigen username loopt. Indien ik bv een Sonarr opzet en deze als root laat starten, dan werkt alles perfect. Maar ik zou graag alles naar Docker krijgen, maar dan moet dit wel in orde komen.

[Splitter]

heb niet alles gelezen (wegens even maar weinig tijd) maar linux + samba + docker gaat wss zowiezo hoofdpijn zijn,
want je docker container draait met user x, terwijl je filesystem user y ziet, en je samba user z wil waarschijnlijk.

chmod 777 zal wss wel werken, maar is natuurlijk afgeraden.

een snelle google geeft 2 resultaten die je mss helpen:

https://thenewstack.io/create-a-samba-s ... container/

[streulma]

Ik heb dit voor mekaar gekregen met :

[share]
path = /mnt/share
writable = yes
guest ok = yes
guest only = yes
force create mode = 775
force directory mode = 775

[StarWing]

@streulma hoe ziet je mount / fstab eruit ?

[bollewolle]

Ik heb nog wat documentatie van mezelf terug gevonden van hoe ik automounts heb geregeld op een Ubuntu systeem (waar ik mijn docker container op draai) naar een NAS. Misschien is het van nut? Mijn excuses dat het in het Engels is (beroepsmisvorming) en voor mogelijk spellingsfouten. Ook geen garanties dat dit nog altijd werkt

Create Mount and Automount with systemd for CIFS/Samba

1. Install cifs-utils as follows:
   

   sudo apt-get install cifs-utils

2. Choose a path where to place a file containing the credentials to access your shared folder. We've used /home/.smbcredentials for example. So create/open the file: > sudo nano /home/.smbcredentials
   
   And put the following in the file (with the correct username and password):

   Code: Selecteer alles

   usename=yourUsername
   password=yourPassword
   

3. First we will mount the audio share of the NAS. These .mount files need to go into the /etc/systemd/system/ folder so navigate to it as follows:
   

   cd /etc/systemd/system/

   Then create the .mount file as follows:
   

   sudo nano mnt-abc_audio.mount

   Fill in the following (use the uid and gid of the user you want to mount with):
   

   Code: Selecteer alles

   [Unit]
   Description=CIFS share audio of NAS ABC
   
   [Mount]
   What=//192.168.XX.YY/audio
   Where=/mnt/abc_audio
   Type=cifs
   Options=rw,credentials=/home/.smbcredentials,_netdev,file_mode=0755,dir_mode=0755,uid=1000,gid=1000
   DirectoryMode=0755
   
   [Install]
   WantedBy=multi-user.target

4. Then configure the automount of this share:
   

   sudo nano mnt-abc_audio.automount/quote]
   And fill in:
   

   Code: Selecteer alles

   [Unit]
   Description=Automount CIFS share audio of NAS ABC
   
   [Automount]
   Where=/mnt/abc_audio
   
   [Install]
   WantedBy=multi-user.target

   [*]This automount is the one we want to enable and start automatically so the following has to be executed:
   

   1. To reload the configuration:
      

      systemctl daemon-reload

   2. To start the unit – so we can use it right away:
      

      systemctl start mnt-abc_audio.automount

   3. To enable the auto-start of the unit:
      

      systemctl enable mnt-abc_audio.automount

   [*]At this point you should be able to cd into the mounted directory /mnt/abc_audio. You can always verify the status by running:
   

   systemctl status mnt-abc_audio.automount

   [*]Note that a reboot might be necessary to finalize the automount itself:
   

   sudo reboot

[StarWing]

En zoals altijd, net nadat je een topic hebt aangemaakt, loop je tegen het goede antwoord aan:

Code: Selecteer alles

//192.168.10.150/media /mnt/media cifs guest,uid=1000

//edit, de uid=1000 was het dus.

[Splitter]

mss een vreemd voorstel, maar: is het probleem énkel met linux machines?
want dan kan je mss beter een sshfs mount (met autofs) gebruiken voor de linux machines (zo mount ik mijn nas & servers naar mijn machines),
dat is (vind ik) veel minder hoofdpijn-opwekkend dan samba, en over het algemeen behaal je er ook betere snelheden mee (omdat het in je lokaal netwerk blijft, kan je de encryptie/compressie uitzetten op de mount)

[StarWing]

Neen, er zitten ook windows machines en een synology bij.

[ITnetadmin]

chmod 777 zal wss wel werken, maar is natuurlijk afgeraden.

Een beetje een late reactie, want het lijkt opgelost, maar dit toch nog effe:
Chmod 777 is zeker nuttig in de testfase, want je sluit daarbij een van de access beperkingen uit, in dit geval die van het file system.
Net zoals ik bij SMB/NTFS ook altijd zeg "zet eentje op full control", zodat je gericht kan testen op 1 probleem ipv het te complex te maken.
Achteraf terug toeschroeven uiteraard