SAMBA op Pi 4B (Buster) werkt niet op mounted Google Drive

[jpvaneijk]

Beste mensen,

Ik heb even wat helderheid nodig. Na avonden zoeken denk ik dat ik iets over het hoofd zie wat waarschijnlijk met een kleine aanpassing kan worden opgelost.

• Configuratie:
• Raspberry Pi 4B draait op Debian Buster (10)
• 2 USB SSD's in ExFat die al gemound zijn
• Google drive voor backup
• RClone voor het maken van een verbinding naar Google Drive

Wat ik wil is:
Google Drive mounten op mijn Raspberry Pi en daarna beschikbaar stellen via Samba binnen mijn netwerk. Hiemee wil ik G-Drive als chijf beschikbaar stellen op verschillende Win10 PC's in het netwerk.

Wat ik gedaan heb:
ik heb hier een uitstekende beschrijving gevonden waarmee ik aan de slag gegaan ben op een fresh install.
Het meest interssante vond ik overigens het doorschakelen naar de ontwikkelaarstool van Google. Hier heb ik een Client code en een secret code weten te bemachtigen waardoor mijn Rclone configuratie als een speer kan synchroniseren.

Ik heb een paar (kleine) aanpassingen moeten doen aan de voorgestelde configuratie omdat Rclone inmiddels een paar versies verder was, evenals mijn OS.
In ieder geval alles werkend en erg happy met mijn Pi servertje!

Waar ik tegenaan loop:
De 2 schijven die al al mijn Pi hangen hebben netjes hun weg in mijn netwerk gevonden middels Samba. AZe zijn zichbaar op het netwerk en, na het invoeren van de gebruikersgegevens (Pi / mijn vast ww) zijn alle directory's te benaderen, te bewerken en te deleten.
Inmiddels is ook de gdrive prima gemound op de Pi en ook opgenomen in de SMB Config.

Voor mijn HDD ziet deze er als volgt uit:

code:

[Backup]
path=media/pi/Backup
writeable=yes
create mask=0777
directory mask=0777
public=no

Voor de gdrive als hieronder:

code:

[Google Drive]
path=home/pi/mnt/gdrive
writeable=yes
create mask=0777
directory mask=0777
public=no

Mijn probleem:
De gdrive is zichtbaar maar niet te openen. Foutmelding als hieronder.



Doe ik iets fout met de rechten voor deze schijf? Moet ik een andere user gebruiken?
Als iemand kan helpen zou dat geweldig zijn. Ik zoek me het lazarus op het www

Thanx in @vance guys!

[Hero of Time]

Het minste wat je nog kan noemen, zijn de rechten (eigenaar en mask) van je mountpoints. Heb je er ook al aan gedacht dat een shared drive die je gemount hebt, niet opnieuw kan delen? Wat als je de bovenliggende map deelt en dan de gdrive map in gaat, wat zie je dan? Misschien werkt dat wel.

[jpvaneijk]

Sorry voor mijn late reactie hoor. Ik ben er zeker al mee aan de slag gegaan.
Voornamelijk met de rechten, maar tot nu toe helpen het toevoegen van valid users, directory masks of publc op yes ook nog niet erg.
Ben weer even met een clean install begonnen. Bovenliggende map (=mnt) op 'rechten voor iedereen' gezet maar ook dat helpt niet om de windowsmelding weg te poetsen.
Ben erg blij met iedere reactie die misschien een lichtje schijnt waar ik nog niet gekeken heb of beter nog, de oplossing.

Voor nu rommel en surf ik door op mogelijke oplossingen, Mijn gevoel zegt dat het iets simpels is waar ik overheen kijk. Maar goed, ik ben ook geen Linux kunstenaar maar wel gedreven om ook zelf tot oplossingen te komen.

Thanx so far!

[Hero of Time]

Je hebt m'n eerste vraag nog niet beantwoord. Nu blijven we maar in een kristallen bol staren zonder iets te zien, want je gegeven informatie is beperkt.

[jpvaneijk]

Kun je aangeven hoe ik dat kan uitlijsten voor je? Ik ben vrij nieuw met Linux.
Merci!

[Hero of Time]

Mijn vraag is het meest simpele om te geven: voer 'ls -l' uit in een map, dan krijg je uitgebreidere informatie te zien over bestanden en mappen die er staan. Daarmee zie je de rechten en eigenaar.

Wat uitgebreider is het log van Samba bekijken, veelal te vinden onder /var/log/samba. Je zal mogelijk root moeten worden om de bestanden te kunnen zien en lezen. Als je de gedeelde map opent en de foutmelding krijgt, en dan het einde van de logs bekijkt zou je met wat mazzel moeten kunnen zien waar die error vandaan komt.

[jpvaneijk]

Oké, dank je. Op ls -l van de gdrive krijg ik:

code:

drwxr-xr-x 1 pi pi 0 mrt  2 17:18 'Documenten van'
drwxr-xr-x 1 pi pi 0 mrt  2 17:43 "Foto's"

'Documenten van' en 'Foto's' zijn de eerste twee mappen die nu in de cloud opslag staan.

In de samba logs kan ik blijkbaar ook kijken zonder root toegang. Er staan echter meerdere logs in waarvan de meest gevulde 'woonkamer' is. Dat is de naam van de PC waarop ik nu werk steeds en het meest mee probeer de gdrive in samba te benaderen.

Inmiddels heb ik ook best wat zitten klooien om toegang te krijgen. Het afgelopen weekend ben ik geholpen door een nette kerel van het Rclone-forum. Wat we gedaan hebben om te onderzoeken staat hier maar helaas nog geen oplossing.

Ik wil de samba woonkamer best posten maar weet even niet hoe dat slim kan. Het zBedankt voor je reactieijn 4.000 woorden. Misschien eerst even schonen en dan een kortere versie plakken?
Bedankt voor je reactie.

[Hero of Time]

De rechten lijken goed, als je met de gebruiker 'pi' inlogt op de share. Dan blijft er niets over dan deze benaderen en de logs bekijken naar de meest recente regels. Makkelijkste is om met SSH in te loggen en dan het volgende te gebruiken, af te sluiten met ctrl+c als je klaar bent:

sudo tail -f /var/log/samba/log.woonkamer

Dit commando start je voordat je de share benadert en na de foutmelding sluit je deze weer.

Let goed op wat er zoal in beeld verschijnt. Kom je er niet uit, kuis het resultaat indien nodig en post de paar regels die je krijgt hier, in code-tags. Als het meer is dan een paar regels, kan je dat eventueel nog omsluiten met quote-tags zodat het standaard ingeklapt is.

[jan99999]

Samba is voor je thuis netwerk. Dit dus ook niet gebruiken naar het internet.

Firewall ? Staat de firewall aan? Staat alles dicht voor google drive? Welke poort gebruikt google drive.
Dus geen samba poorten naar het internet openen voor google drive.

Misschien in je router een poort door sturen naar naar de pc die google drive gebruikt, hier ook welke poort is nodig.

-Als alles op je pi werkt tav samba, dan zou dit goed moeten zijn.
-Google drive zou geen samba moeten zijn, want dit is extern, en dat mag niet.
-Linux mount niet alles vanzelf, dus open met de verkenner die je gebruikt, dan is het verbonden, dan kun je proberen of het werkt.

[jpvaneijk]

Hero of Time schreef op dinsdag 10 maart 2020 @ 17:19:

Let goed op wat er zoal in beeld verschijnt. Kom je er niet uit, kuis het resultaat indien nodig en post de paar regels die je krijgt hier, in code-tags. Als het meer is dan een paar regels, kan je dat eventueel nog omsluiten met quote-tags zodat het standaard ingeklapt is.

Dit hieronder staat nu in de logfile. Ben benieuwd welke sope ervan te maken valt.

[2020/03/10 21:05:30.335173, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive
[2020/03/10 21:05:30.364967, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive
[2020/03/10 21:05:30.379381, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive
[2020/03/10 21:05:30.386710, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive
[2020/03/10 21:05:30.407585, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive
[2020/03/10 21:05:30.416640, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive
[2020/03/10 21:05:30.427726, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive
[2020/03/10 21:05:32.467454, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive
[2020/03/10 21:05:32.469890, 0] ../source3/smbd/service.c:782(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive

[jpvaneijk]

jan99999 schreef op dinsdag 10 maart 2020 @ 19:56:
Samba is voor je thuis netwerk. Dit dus ook niet gebruiken naar het internet.
Daar is het gelukkig ook niet voor nodig, Wel voor op het lokale netwerk.

Firewall ? Staat de firewall aan? Staat alles dicht voor google drive? Welke poort gebruikt google drive.
Dus geen samba poorten naar het internet openen voor google drive.
Ik heb alleen voor Rclone poort 53682 opengezet in mijn router. Een firewall op de Pi heb ik (nog) niet geinstalleerd

Misschien in je router een poort door sturen naar naar de pc die google drive gebruikt, hier ook welke poort is nodig.
Hier lees ik welke poorten samba zou gebruiken. Deze gebruik ik niet en heb ik voor de twee SSD die via USB aangesloten zijn ook niet.

-Als alles op je pi werkt tav samba, dan zou dit goed moeten zijn.Toch lijkt er iets met de permissies of rechten iets niet goed te zijn?
-Google drive zou geen samba moeten zijn, want dit is extern, en dat mag niet. Dat realiseer ik me wel maar delen in eigen netwerk moet toch kunnen?
-Linux mount niet alles vanzelf, dus open met de verkenner die je gebruikt, dan is het verbonden, dan kun je proberen of het werkt.

[HJT!]

Om de rechten goed te bekijken moet je eigenlijk een ls -l uitvoeren in /home/pi/mnt/ want juist de rechten van de map gdrive zijn interessant.

Verder werken spaties vaak tegen, ik zou het eens zonder spatie in de sharenaam proberen.

[jpvaneijk]

HJT! schreef op dinsdag 10 maart 2020 @ 21:28:
Om de rechten goed te bekijken moet je eigenlijk een ls -l uitvoeren in /home/pi/mnt/ want juist de rechten van de map gdrive zijn interessant.

Verder werken spaties in IT-land vaak tegen, ik zou het eens zonder spatie in de sharenaam proberen.

Dit zijn de rechten die ik uit mnt heb gehaald. Ik heb inderdaad de spaties verwijderd uit de sharenaam o.b.v. een eerdere tip die ik op het Rclone forum kreeg.

pi@Server:~/mnt $ ls -l
totaal 0
drwxr-xr-x 1 pi pi 0 mrt 8 20:41 gdrive
pi@Server:~/mnt $

[Hero of Time]

Dit zegt genoeg:

code:

make_connection_snum: canonicalize_connect_path failed for service gdrive, path /home/pi/mnt/gdrive

Het kan het pad niet fatsoenlijk vertalen naar een werkbare URI voor het SMB protocol. Precies wat ik in m'n eerste post al aangaf: waarschijnlijk gaat het benaderen van een reeds op het netwerk aanwezige locatie niet werken.

Je zou op deze melding verder kunnen zoeken met Google, maar het lijkt mij zinvoller om je Gdrive gewoon op je client te installeren om zo je bestanden te kunnen benaderen.

[jpvaneijk]

Dat klinkt niet onlogisch moet ik eerlijk bekennen, maar zover ben ik zelf nog niet.
Ik kan me (bijna) niet voorstellen dat er niet een enigzins simpele of op z'n minst begrijpelijke oplossing voor iets als dit is.

Ik wil zeker niet dwars zijn of beter weten want dat kan ik helemaal niet. Maar ik heb al teveel oplossingen gezien voor grotere issues als dit. MIsschien een virtuele URL, toch iets met de rechten, een bepaalde poort openzetten of in Windows iets aanpassen. Geen idee.

In ieder geval bedankt voor het meedenken Hero of Time. Erg blij met de geinvesteerde tijd!

[HJT!]

Lastig te zeggen zo, ik heb nog enkele ideeen;

path=home/pi/mnt/gdrive wijzigen naar path=/home/pi/mnt/gdrive

Daarna samba even herstarten: sudo systemctl restart smbd

Als dat niet helpt de execute bit controleren of aanzetten voor bovenliggende directories:

chmod -R a+x /home/ (Vervolgens samba weer herstarten)

Je kunt ook nog in je smb4.conf de “ Server min protocol” op NT1 zetten.
Samba weer herstarten en weer testen. Terugzetten als het niet helpt.

Als laatste zou ik een andere directory aanmaken onder media, en die proberen te delen. Werkt dat dan daarna de synchronisatie met Google drive in die directory werkend zien te krijgen.

Andere strategie is om een symbolische link aan te maken in media die verwijst naar gdrive, en dan de symbolic link aan samba toe te voegen.

[ Voor 85% gewijzigd door HJT! op 10-03-2020 22:26 ]

[Hero of Time]

HJT! schreef op dinsdag 10 maart 2020 @ 22:15:
Als dat niet helpt de execute bit controleren of aanzetten voor bovenliggende directories:

chmod -R a+x /home/ (Vervolgens samba weer herstarten)

Dat is bijna hetzelfde als alles op 777 smijten. Waarom zou je in vredesnaam alles in /home executable maken? Het garandeert iig wel dat je ssh keys niet meer werken.

[jpvaneijk]

Toch zijn dit nog wel slimme ideetjes die ik zoek. Wat ik dus gedaan heb is eerst even een verse Debian Buster installatie erop en daarna de tips gevolgd:

path=home/pi/mnt/gdrive wijzigen naar path=/home/pi/mnt/gdrive
Daarna samba even herstarten: sudo systemctl restart smbd

Gedaan: Maakte helaas niets uit.

chmod -R a+x /home/ (Vervolgens samba weer herstarten)

Gedaan: Maakte helaas niets uit

Als laatste zou ik een andere directory aanmaken onder media, en die proberen te delen. Werkt dat dan daarna de synchronisatie met Google drive in die directory werkend zien te krijgen.

Dit leek me ook een logische zeg. Ik heb de gdrive dus gemount in de (reeds in samba aanwezige) Backup schijf. In mijn Pi is deze ook gewoon zichtbaar en toegankelijk. Zie hieronder:


Hij is echter niet in de sambashare binnen Win10 zichtbaar


Ik heb de gdrive ook nog apart opgenomen in samaconfig dat maakte helaas ook niet uit

code:

[gdrive]
path=/media/pi/Backup/gdrive
writeable=Yes
create mask=0777
directory mask=0777
public=no

Als ik naar de rechten kijk in de gdrive:

code:

pi@Server:/media/pi/Backup/gdrive $ ls -l
totaal 0
drwxr-xr-x 1 pi pi 0 mrt  2 17:18 'Documenten van'
drwxr-xr-x 1 pi pi 0 mrt  2 17:43 "Foto's"

Je kunt ook nog in je smb4.conf de “ Server min protocol” op NT1 zetten.
Samba weer herstarten en weer testen. Terugzetten als het niet helpt.

Hoe doe ik dit? Wil het best proberen maar weet niet hoe ik dit doe?

Wat mij betreft lijkt het me een juiste aanvliegroute om eerst te kijken hoe en of ik gdrive in de de share-omgeving krijg en daarna te kijken hoe en op welke manier ik dit netjes kan beveiligen. Ik ben erg blij met je toevoegingen HJT!. Helaas nog niet het gewenste resultaat en gdrive staat op dit moment op 777:


Nog andere opties in je arsenaal? Op het internet kom ik hier ook bijzonder weinig over tegen. Word er wel een beetje moedeloos van maar heb nog zeker puf om door te prutten.

Merci!

EDIT: HET IS OPGELOST

Zoals ik al vermoedde zat de oplossing in een heel klein dingetje. Ik hoop dat het nog een hoop anderen kan helpen.
Op het web vond ik deze simpele evenals heldere oplossing.
Ik heb eerst onderin de fuse.conf user_allow_other toegevoegd

code:

cd /etc
sudo nano fuse.conf

Daarna heb ik aan de mount --allow-other toegevoegd. De mount ziet er nu als volgt uit:

code:

rclone mount gdrive: $HOME/mnt/gdrive --allow-other

Daarnaast had ik nog even een probleem het het auto-mounten van de schijf. Dat heb ik op weten te lossen door de [e-mail] file aan te passen. Daar heb ik dus ook --allow-other tussen gezet. Zie hieronder:

[Unit]
Description=rclone: Remote FUSE filesystem for cloud storage config %i
Documentation=man:rclone(1)

[Service]
Type=notify
ExecStartPre=/bin/mkdir -p %h/mnt/%i
ExecStart= \
/usr/bin/rclone mount \
--fast-list \
--vfs-cache-mode writes \
--vfs-cache-max-size 100M \
--allow-other \
%i: %h/mnt/%i

[Install]
WantedBy=default.target

Ik kan nu precies wat ik wil met deze sambashare.
Iedereen ontzettend bedankt voor het meedenken en kijken. Erg blij mee! Deze topic kan op slot wat mij betreft.

Klein dingetje misschien nog. Ik lijk de bestanden die ik open en berwerk niet meer op te kunnen slaan omdat het wijzigen ervan niet wordt toegestaan. Is er ook een 'Flag' of iets dergelijks waarmee ik dat op los?

[ Voor 26% gewijzigd door jpvaneijk op 14-03-2020 19:52 ]