Ubuntu 22.04, samba, transmission

[StarWing]

Ik ben hier ondertussen een dag of 2 mee aan het stoeien, maar een oplossing heb ik nog niet gevonden, waarschijnlijk zie ik iets dom over het hoofd, maar ik kom er niet uit.

Ik heb 2 ubuntu servers:

1 machine welke dient als fileserver met samba geïnstalleerd, en 1 share aktief.
1 machine met enkele download clients op, met oa Transmission.

Aangezien transmission draait onder zijn eigen username, heeft deze geen toegang tot de samba share op de fileserver.
Andere clients zoals sabnzbd, welke onder root draaien, hebben zonder problemen RW toegang tot deze share.
Het aanpassen van de username in Transmission is ook een dingetje, dit veroorzaakt dat transmission niet of niet goed meer werkt. Althans als ik het doe, start deze niet meer op omdat de rechten op de cfg files verprutst zijn. Ik heb een poging ondernomen om deze goed te zetten, en ik slaag erin van TM terug op te starten, maar ik krijd nog steeds een access denied als ik een download wil starten.
De guides op google zijn hierover onduidelijk en enkele jaren oud.

Verschillende zaken aangepast zowel aan de server als client zijde, maar niets lijkt te werken.
Op zich zou ik gewoon graag 777 hebben, rechten boeien me niet in deze setup, deze is prive en hangt niet aan het internet.

Fileserver:

code:

vembyserver@vembyserver:/opt/media/downloads$ ls -l
total 12
drwxrwxrwx 2 nobody nogroup 4096 Dec  6 06:56 complete
drwxrwxrwx 2 nobody nogroup 4096 Dec  6 06:56 incomplete
drwxrwxrwx 2 nobody nogroup 4096 Dec  5 19:01 transmission

code:

[Media]
    comment = Emby Server
    path = /opt/media
    browsable = yes
    guest ok = yes
    read only = no
    create mask = 0777
    directory mask = 0777
    writable = yes

Download server:

code:

vmedia@vmediaserver:/etc$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during curtin installation
/dev/disk/by-uuid/a3478552-dfd3-47e7-91b6-a9a4cca66d74 / ext4 defaults 0 1
/swap.img       none    swap    sw      0       0

//192.168.10.150/media /opt/media cifs rw,file_mode=0777,dir_mode=0777 0 0

==> met deze lijn heb ik verschillende zaken geprobeerd, maar de goede combo nog niet tegengekomen.

code:

vmedia@vmediaserver:/opt/media/downloads$ ls -l
total 0
drwxr-xr-x 2 root root 0 Dec  6 06:56 complete
drwxr-xr-x 2 root root 0 Dec  6 06:56 incomplete
drwxr-xr-x 2 root root 0 Dec  5 19:01 transmission
vmedia@vmediaserver:/opt/media/downloads$

Op de directory "transmission" zou de transmission client schrijfrechten moeten hebben.
Ook heb ik reeds geprobeerd van de dir te chown-en, maar dit blijkt niet echt te werken op een SMB share.
chmod -R 777 tranmission doet ook niets op de client server.

Iemand de gouden tip ?

[Cyphax]

Ik zou beginnen met het opnemen van de username (en group) in je fstab. Ik doe het zelf zo:

//192.168.*.*/nextcloud /mnt/fileserver cifs credentials=/etc/smbcredentials,rw,uid=www-data,gid=www-data,dir_mode=0770,file_mode=0770 0 0

smbcredentials is een file die alleen door root gelezen kan worden. Ziet er ongeveer zo uit:

code:

username=[username]
password=[password]
domain=WORKGROUP

Als je smb-gebruiker overeenkomt met de gebruiker op de server, dan zou het moeten werken, als je niet intussen de rechten op de share zo hebt aangepast dat dat in de weg gaat zitten.

[StarWing]

Je bedoelt dan root of de username van de transmission ? (da's wel een dingetje, deze is auto generated en weet ik bijgevolg niet)

[Hero of Time]

Op je fileserver heeft de map die je deelt als eigenaar 'nobody' en 'nogroup'. Dat is niet standaard, waarom heb je dit zo ingesteld? Ik zou hier een normale gebruiker of anders root verwachten. Sowieso moet de groep waar Samba onder draait in de mappen kunnen die je deelt. De eigenaar zal dan de gebruiker moeten zijn waarmee je op de share inlogt, die je in de credentials invult om de share te mounten op de Transmission server.

Wat betreft gebruikersnaam van Transmission opnemen in fstab als uid= en gid=, dat kan het beste standaardiseren. Als het UID altijd gelijk is maar de naam is anders, dan vul je het numerieke ID in. Wel vreemd trouwens als de gebruiker waaronder Transmission draait telkens anders is. Hoe doe je dat precies? Want ook dat is geen standaard configuratie.

[StarWing]

Hoe doe je dat precies? Want ook dat is geen standaard configuratie.

Ik heb de tranmission repo toegevoegd, dan apt update & apt install transmission
Dan maakt deze standaart een gebruiker aan.

[Cyphax]

StarWing schreef op woensdag 6 december 2023 @ 08:40:
Je bedoelt dan root of de username van de transmission ? (da's wel een dingetje, deze is auto generated en weet ik bijgevolg niet)

Dat zouden de user en wachtwoord moeten zijn die je met smbpasswd voor transmission instelt. Dat hoeven niet dezelfde naam en wachtwoord te zijn als van de user op het besturingssysteem maar je moet wel de koppeling maken met de bestaande user, die moet je dan even achterhalen. Als je ps aux uitvoert kan je misschien de user achterhalen die het proces van transmission heeft gestart.

[Hero of Time]

StarWing schreef op donderdag 7 december 2023 @ 05:32:
[...]

Ik heb de tranmission repo toegevoegd, dan apt update & apt install transmission
Dan maakt deze standaart een gebruiker aan.

Oh, maar dat is dan alleen op moment van installeren (updates doen er niets mee, want de gebruiker bestaat al). Ik dacht dat je het via een container of zo wilde draaien en op die manier telkens een andere naam of UID hebt. Maar als het met het package uit hun repo komt, kan je gewoon de naam gebruiken, want die zou hetzelfde moeten zijn, ongeacht of het UID nou 503 of 1002 is, of wat dan ook.

[synoniem]

code:

[Media]
    comment = Emby Server
    path = /opt/media
    browsable = yes
    guest ok = yes
    read only = no
    create mask = 0777
    directory mask = 0777
    writable = yes

Kan je nog toevoegen.

code:

    force user = username
    force group = groupname

Als je dan met smbpasswd de gebruiker toevoegt en

code:

sudo chmod -R username:groupname /opt/media

Kan je met die gebruikersinformatie fstab op de downloadserver invullen. De fileserver weet niet welke "echte" gebruiker achter die naam zit.

[StarWing]

Ondertussen opgelost, voor de volledigheid:

code:

/etc/systemd/system/multi-user.target.wants/transmission-daemon.service

bewerken naar username=root

configfile kopieren naar nieuwe ./config, eenmaal de gebruiker aangepast, staat de config ergens anders:

code:

/root/.config/transmission-daemon/settings.json

fstab aanpassen:

code:

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

Het aanpassen van de fstab zorgde er in eerste instantie voor dat ik als non-root files kon aanpassen/maken. Ik dacht dat hiermee de kous af was. Helaas kreeg ik nog steeds een access denied bij Transmission. Waarom, geen idee.
Naderhand nog de gebruiker van Transmission aangepast naar root en de settings.json gekopieerd naar de home dir.

[ Voor 4% gewijzigd door StarWing op 08-12-2023 05:50 ]

[Hero of Time]

Dit is geen oplossing. Iets zonder duidelijk te weten wat er mis is maar onder de root gebruiker uitvoeren, een gebruiker die alles kan en mag, is niet verstandig.

Beter ga je verder met debuggen waarom het niet werkte. Je hebt bijvoorbeeld in fstab 'uid=1000' staan, terwijl je eerder aangaf dat het Transmission package een eigen gebruiker maakte. Die moet je daar invullen ipv 1000.

[StarWing]

100% mee eens, maar het is voor prive gebruik, en is niet benaderbaar extern. In een productieomgeving zou ik het inderdaad anders doen.
Maar de uid=1000 was wel de oplossing, vanaf de moment dat ik deze toegevoegd had en een restart kon ik de nodige mappen aanmaken.

[Hero of Time]

Maar daarmee kon je met je eigen gebruiker de mappen maken. Transmission draaide dus nog steeds onder een andere gebruiker. Zet nou eens ipv 'root' jouw gebruikersnaam in de systemd unit voor Transmission.

[StarWing]

Hero of Time schreef op zaterdag 9 december 2023 @ 13:41:
Maar daarmee kon je met je eigen gebruiker de mappen maken.

Neen, dat kon ik niet. Ik kon enkel aanmaken/verwijderen als root op het guest systeem.

[Hero of Time]

Dan heeft het toevoegen van UID=1000 niks verandert aan functionaliteit en kijk je naar confirmation bias te kijken. Je doet iets en denk dat door die ene wijziging het opeens wel werkt. Maar je had nog steeds root rechten nodig, dus effectief was die wijziging niet de oplossing.