Raspian Samba share geen toegang

[Christian_Ku]

Een raspberry pi 2 draait bij mij als NAS en ik heb net een extra share toegevoegd, een USB HDD. Er zijn nu in totaal 3 schijven gekoppeld, allemaal gedeeld op het netwerk via samba. De eerste twee verliepen vlekkeloos en ik heb ook gewoon toegang op mijn windows laptop. De derde, helaas, vraagt om een wachtwoord, welke na invoeren geen resultaat geeft en gewoon opnieuw vraagt om een wachtwoord. ALLE settings in de smb.conf zijn identiek (lees gekopieerd). Ik snap niet wat ik hier fout doe. Al flink gegoogled maar dit probleem lijkt zich niet vaak voor te doen.

Ik heb al de 'security = user' line gedeactiveerd maar dat biedt geen soelaas, wederom een password prompt. Ook al gerestart. Andere user maakt ook niet uit. Waar zit het hem in?

[Hero of Time]

Zonder config kunnen we natuurlijk niets. Het minste wat je dus nog aan je OP moet toevoegen is je Samba config.

Zie je verder nog iets in de logs? Kan je vanaf de Pi wel gewoon de schijf benaderen?

[Christian_Ku]

Ik zie de schijf gewoon, vanaf de pi is het ook geen probleem. Werkt allemaal.

De config voor de schijf is als volgt:

[Backup]
comment = Backup Folder
path = /media/USBHDD1/shares
valid users = @users
force group = users
create mask = 0660
directory mask = 0771
read only = no

logs laten niets vreemds zien voor zover ik dat kan beoordelen.

[Hero of Time]

En de andere mappen dan die je deelt? Wat zijn de file system rechten op de betreffende mappen? Wat zie je in smb.log? Vreemde dingen oordelen wij wel, want jij zit met een probleem.

[Christian_Ku]

Filesystem rights zijn als volgt:

code:

  File: /media/Backup;
  Size: 12288           Blocks: 24         IO Block: 4096   directory
Device: 821h/2081d      Inode: 5           Links: 1
Access: (0700/drwx------)  Uid: ( 1000/      pi)   Gid: ( 1000/      pi)
Access: 2016-07-31 10:57:12.563256900 +0200
Modify: 2016-07-30 17:29:06.995095700 +0200
Change: 2016-07-30 17:29:06.995095700 +0200

Voor de andere mappen geldt:

code:

  File: /media/USBHDD_IB1.5t/
  Size: 16384           Blocks: 32         IO Block: 4096   directory
Device: 811h/2065d      Inode: 5           Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2016-07-30 19:59:33.337120200 +0200
Modify: 2016-06-02 16:28:51.338411400 +0200
Change: 2016-06-02 16:28:51.338411400 +0200

  File: /media/USBHDD_IB1t/
  Size: 12288           Blocks: 24         IO Block: 4096   directory
Device: 801h/2049d      Inode: 5           Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-12-22 10:45:52.937500000 +0100
Modify: 2016-06-28 21:40:37.598981800 +0200
Change: 2016-06-28 21:40:37.598981800 +0200

Andere mappen config:

code:

[IBHDD_1t]
comment = 1tb HDD from ICYBOX
path = /media/USBHDD_IB1t/
valid users = @users
force group = users
create mask = 0660
directory mask = 0771
read only = no

[IBHDD_1.5t]
comment = 1.5tb HDD from ICYBOX
path = /media/USBHDD_IB1.5t/
valid users = @users
force group = users
create mask = 0660
directory mask = 0771
read only = no

Voor de log staat er in de specifieke log file voor mijn laptop (log.LAPTOP) dit:

canonicalize_connect_path failed for service Backup, path /media/Backup

(smb.log bestaat niet en log.smbd en log.nmbd zijn leeg)

Nu ben ik ook niet helemaal achterlijk en zie ik nu inderdaad dat er verschillende rights zitten op Backup en de andere twee mappen, MAAR, heeft dat dan ook effect op het kunnen inloggen op de share?! Waarom zou dat anders moeten zijn.

[ Voor 0% gewijzigd door Hero of Time op 31-07-2016 11:24 . Reden: Leesbaarheid is alles ]

[Hero of Time]

De rechten hebben direct effect op het wel of niet toegankelijk zijn van de shares. Als je een gebruiker hebt, christian bijvoorbeeld, met UID 1000. De map die je deelt, waar de geldige gebruiker christian is, heeft rechten 750. Dat is dus gebruiker mag alles, groep mag lezen, alle andere gebruikers mogen niets. Dan kom je er alsnog niet in. Reden: Samba draait onder een andere gebruiker. En die mag niet in de map.

De beste rechten zijn 751 danwel 755 (weet even niet welke werkt, moet je even testen).

[Christian_Ku]

OK, het volgende snap ik niet. Naast rechten zag ik ook dat de owner anders was, de beide ICYBOX schijven vielen allebei onder root:root waar de Backup onder pi:pi viel. Niet juist want dan kan de user 'media' er niet bij. Ik dus:

sudo chown root:root -R /media/Backup

verandert er niks.

Output ls -l /media is nog steeds:

drwx------ 1 pi pi 12288 Jul 30 19:29 Backup

ook sudo chmod 755 /media/Backup heeft geen enkel effect op de rechten. Hoe kan dat?

[Hero of Time]

Omdat het file system dat je wilt wijzigen niet POSIX compliant is. Je schijf is NTFS of FAT32 en valt daar dus niet onder. De effectieve rechten worden bepaald door de mount opties.

[ Voor 12% gewijzigd door Hero of Time op 02-08-2016 10:21 ]

[Christian_Ku]

juist, en dat verklaart dus ook waarom de een een directory is volgens de colorscheme en de andere een 'other writable'

en dus werkte:

sudo mount -o rw etcetc

WEL! Eindelijk, Backup valt nu onder root:root met alle rechten. Dank!

[Hero of Time]

En als je mount met de opties 'uid=<nummer>,gid=<nummer>' dan kan je de user en groep eigenaar opgeven.

[Christian_Ku]

OK, ander probleem, ik heb een andere schijf aan een tweede RPi hangen, en die wil ik mounten als een netwerk share. Nu, dat lukt allemaal prima, alleen krijg ik geen schrijf rechten. Wat ik ook probeer:

- dir aangemaakt in media, met juiste user, daar (zonder mount) schrijf rechten en de hele rimram op, schijf wordt gemount (sudo mount -t cifs -o user etc) en vervolgens vervallen de schrijf rechten.
- users gewisseld, uid en gid gebruikt, maakt allemaal niet uit

Hier moet wel bij vermeld, die schijf hangt aan een OSMC kodi, en die samba conf is anders.

config file = /etc/samba/smb-local.conf

workgroup = WORKGROUP
security=user
follow symlinks = yes
wide links = no
unix extensions = no
lock directory = /var/cache/samba
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes

[Hero of Time]

Je hebt twee plekken waar je rechten op moet geven. Lokaal aan de server kant, zowel de schijf die je deelt moet rechten hebben voor een gebruiker die je tevens gebruikt om mee te verbinden en aan de client kant via de mount opties, met daarbij dus de gebruiker die moet schrijven terwijl je bij de authenticatie de gebruiker op de server kant gebruikt die mag schrijven op de schijf. Je logs zouden alles moeten aangeven waar het fout gaat.

[vso]

Christian_Ku schreef op donderdag 11 augustus 2016 @ 21:19:

probeer eerst een de situatie te schets per issue.
- waarmee connect je ? windows \\,ip\sharenaam ?
- wat is de config --> #cat /etc/samba/smb.conf
- wat is er geinstalleerd voor samba

bijvoorbeeld
#sudo apt-get install samba samba-common-bin krb5-kdc krb5-admin-server ntp

Uitgaande van windows kan je winscp/putty gebruiken om makkelijk in te loggen en de config copy en paste te doen. ander OS andere software

Samba heeft logging (restart samba) google hier anders op..
meerdere putty(lees terminal) sessies vanaf je desktop en dus meerdere vensters maakt het soms wel makkelijker ..

in 1 sessie kan je bv
#tail -f /var/log/messages
wat je oplevert = als samba een fout in /var/log/messages gooit kan je dit direct zien ..
google anders op samba logging .. let wel je kan deze ook meer/minder laten loggen vereist wel samba restart.

je kan eventueel met nmap of telnet of poortscanner even je 2de RPi scannen of de poort 139 open staat.;.
dit zou ook kunnen met het commando
#netstat -a | more
maar hiermee zie je niet of een firewall ofzoiets je netwerk blokkeert.

maar kodi heeft een iptables firewall als ik snel ff google ..

iptables -A TCP -p tcp --match multiport --dports 139 -m comment --comment "samba" -j ACCEPT
iptables-save > /etc/iptables/iptables.rules
systemctl reload iptables

google er ook zelf op voordat je dat dit doet

[Christian_Ku]

Gisteren bezig met wijzigen post waarna ik werd weggeroepen van PC. Maar ik zie dat de reactie snelheid hier hoger ligt dan mijn typecapaciteit! Dank beiden.

@ Hero: hdd hangt aan OSMC rpi, user daar heeft alle rechten (drwxrwxrwx), user op NAS pi duidelijk niet. Daar zit hem dus ook wederom het probleem. Serieus zitten mounten, ook met dir_mode en file_mode maar dat maakt niet uit. Me intussen helemaal suf gegoogled maar kom er niet echt uit. Logs laten het volgende zien aan de OSMC kant:

log.smbd
[2016/08/12 08:54:27.378514, 0] ../source3/lib/util.c:788(smb_panic_s3)
PANIC (pid 31762): internal error
[2016/08/12 08:54:27.905121, 0] ../source3/lib/util.c:899(log_stack_trace)
BACKTRACE: 0 stack frames:
[2016/08/12 08:54:27.908440, 0] ../source3/lib/dumpcore.c:318(dump_core)
dumping core in /var/log/samba/cores/smbd
[2016/08/12 08:54:29.878914, 1] ../source3/smbd/server.c:462(remove_child_pid)
Scheduled cleanup of brl and lock database after unclean shutdown
[2016/08/12 08:54:49.879641, 1] ../source3/smbd/server.c:407(cleanup_timeout_fn)
Cleaning up brl and lock database after unclean shutdown

nmbd version 4.2.10-Debian started.
Copyright Andrew Tridgell and the Samba Team 1992-2014
[2016/08/11 22:17:48.956615, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2016/08/11 22:58:21.062030, 0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
query_name_response: Multiple (2) responses received for a query on subnet 10.0.0.2 for name WORKGROUP<1d>.
This response was from IP 10.0.0.3, reporting an IP address of 10.0.0.3.
[2016/08/11 23:13:30.717618, 0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
query_name_response: Multiple (2) responses received for a query on subnet 10.0.0.2 for name WORKGROUP<1d>.
This response was from IP 10.0.0.3, reporting an IP address of 10.0.0.3.

aan de NAS kant staat er niks in de logs. Ik heb intussen ook het log level omhoog gegooid, tot nu toe nog geen resultaat.

@vso: ik verbind via putty, probeer schijf vna OSMC te mounten op mijn NAS (ja klinkt onlogisch maar is even nodig), voor de logs zie bovenaan. Voor Samba zijn alle noodzakelijke opties geinstalleerd.

[Hero of Time]

Goed, je gaat dit eens anders oplossen. Aangezien je van Linux naar Linux gaat, heeft alles gewoon SSH support. Je kan ook file systems mounten over SSH, via SSHFS. Dit is een apart package dat via fuse een remote systeem kan mounten. Het is dan zo simpel alsof je scp gebruikt, alleen is het resultaat het mounten van de schijf. Zie https://github.com/libfuse/sshfs. Je hoeft het niet vanaf broncode te compileren, het zit in de Raspian repo als 't goed is.

Andere optie is om het via NFS te doen.

Samba is leuk, maar eigenlijk alleen noodzakelijk als je met Windows systemen te maken hebt. Voor de rest zijn er betere opties beschikbaar.

[Thc_Nbl]

als je nu eens het volgende doet.

security = user
map to guest = Bad User

en in je share zet je :
public = yes
only guest = yes
writable = yes

Dat zou moeten werken voor een passwordless share.

Gr.

[ Voor 4% gewijzigd door Thc_Nbl op 12-08-2016 12:58 ]

[Christian_Ku]

Dank Hero, ga ik eens bekijken. Had inderdaad al naar NFS mogelijkheden gekeken aangezien het inderdaad van linux naar linux gaat.

@Nbl ga ik ook proberen.

[vso]

Christian_Ku schreef op vrijdag 12 augustus 2016 @ 09:55:
Gisteren bezig met wijzigen post waarna ik werd weggeroepen van PC. Maar ik zie dat de reactie snelheid hier hoger ligt dan mijn typecapaciteit! Dank beiden.

@ Hero: hdd hangt aan OSMC rpi, user daar heeft alle rechten (drwxrwxrwx), user op NAS pi duidelijk niet. Daar zit hem dus ook wederom het probleem. Serieus zitten mounten, ook met dir_mode en file_mode maar dat maakt niet uit. Me intussen helemaal suf gegoogled maar kom er niet echt uit. Logs laten het volgende zien aan de OSMC kant:

log.smbd
[2016/08/12 08:54:27.378514, 0] ../source3/lib/util.c:788(smb_panic_s3)
PANIC (pid 31762): internal error
[2016/08/12 08:54:27.905121, 0] ../source3/lib/util.c:899(log_stack_trace)
BACKTRACE: 0 stack frames:
[2016/08/12 08:54:27.908440, 0] ../source3/lib/dumpcore.c:318(dump_core)
dumping core in /var/log/samba/cores/smbd
[2016/08/12 08:54:29.878914, 1] ../source3/smbd/server.c:462(remove_child_pid)
Scheduled cleanup of brl and lock database after unclean shutdown
[2016/08/12 08:54:49.879641, 1] ../source3/smbd/server.c:407(cleanup_timeout_fn)
Cleaning up brl and lock database after unclean shutdown

nmbd version 4.2.10-Debian started.
Copyright Andrew Tridgell and the Samba Team 1992-2014
[2016/08/11 22:17:48.956615, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2016/08/11 22:58:21.062030, 0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
query_name_response: Multiple (2) responses received for a query on subnet 10.0.0.2 for name WORKGROUP<1d>.
This response was from IP 10.0.0.3, reporting an IP address of 10.0.0.3.
[2016/08/11 23:13:30.717618, 0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
query_name_response: Multiple (2) responses received for a query on subnet 10.0.0.2 for name WORKGROUP<1d>.
This response was from IP 10.0.0.3, reporting an IP address of 10.0.0.3.

aan de NAS kant staat er niks in de logs. Ik heb intussen ook het log level omhoog gegooid, tot nu toe nog geen resultaat.

@vso: ik verbind via putty, probeer schijf vna OSMC te mounten op mijn NAS (ja klinkt onlogisch maar is even nodig), voor de logs zie bovenaan. Voor Samba zijn alle noodzakelijke opties geinstalleerd.

toon volledige bericht

neuh onlogisch is niet relevant .. je wilt A mounten op B

Voor probleem analyse .. probeer top down te achterhalen waar je issue zit ..
0) netwerk
1) firewall
2) service
Hierin zou ik eerst achterhalen of je vanaf osmc uberhaupt bij de NAS kan komen ..
Probeer te elimineren waar je issue niet zit.

Telnet <poort> of poortscan (nmap) naar de NAS, een firewall uit zetten is obvious, maar aanzetten in log modus op de 139(SMB poort) is minder gebruikt maar in mijn beleving wel handig als je wilt troubleshooten.

Zo kwam ik er achter dat een systeem een uur achter liep.. en omdat men vaak uren na event x pas gingen zoeken kwam men er nooit achter. Toen ik binnenkwam en net een dergelijk event elders had gehad. .. <etcerta>

Er is veel mogelijk, en een netcat log op poort 139 (of andere poort) wel samba uitzetten! Zie je teminste dat er data binnekomt en tegen de server gebabbeld word. scheelt je overgens ook in logs baggeren

Hero of Time schreef op vrijdag 12 augustus 2016 @ 11:25:
Goed, je gaat dit eens anders oplossen. Aangezien je van Linux naar Linux gaat, heeft alles gewoon SSH support. Je kan ook file systems mounten over SSH, via SSHFS. Dit is een apart package dat via fuse een remote systeem kan mounten. Het is dan zo simpel alsof je scp gebruikt, alleen is het resultaat het mounten van de schijf. Zie https://github.com/libfuse/sshfs. Je hoeft het niet vanaf broncode te compileren, het zit in de Raspian repo als 't goed is.

Andere optie is om het via NFS te doen.

Samba is leuk, maar eigenlijk alleen noodzakelijk als je met Windows systemen te maken hebt. Voor de rest zijn er betere opties beschikbaar.

Zeker een punt, echter IMHO als de TS kiest voor universeel wegens allemaal diverse clients zou ik hem niet op een dwaalspoor willen zetten (als test / nood is dit echter wel handig)
Maar via MC(Midnight Commander) een SCP opzetten voor nood copieren van data is hierin vele malen sneller makkelijker .. hiervoor hoef je niet eens SSHFS te installeren .. (wel mc ) maar goed dit is een redelijk universeel product.

[Hero of Time]

vso schreef op zondag 14 augustus 2016 @ 01:52:
[...]

Zeker een punt, echter IMHO als de TS kiest voor universeel wegens allemaal diverse clients zou ik hem niet op een dwaalspoor willen zetten (als test / nood is dit echter wel handig)
Maar via MC(Midnight Commander) een SCP opzetten voor nood copieren van data is hierin vele malen sneller makkelijker .. hiervoor hoef je niet eens SSHFS te installeren .. (wel mc ) maar goed dit is een redelijk universeel product.

Ja, maar initieel was het ook gelukt. Het ging weer mis bij de tweede schijf die hij beschikbaar wilde maken en dat was van Pi naar NAS. Dat is 1 client en Samba is dan niet de meest ideale oplossing. Zeker gezien de problemen en relatieve moeilijkheid om het op te lossen.

Samba is prachtig als het werkt, maar kan een hel zijn als je problemen hebt.

[vso]

Hero of Time schreef op zondag 14 augustus 2016 @ 11:00:
[...]

Ja, maar initieel was het ook gelukt. Het ging weer mis bij de tweede schijf die hij beschikbaar wilde maken en dat was van Pi naar NAS. Dat is 1 client en Samba is dan niet de meest ideale oplossing. Zeker gezien de problemen en relatieve moeilijkheid om het op te lossen.

Samba is prachtig als het werkt, maar kan een hel zijn als je problemen hebt.

Jup

Daarom begin in bij "binnenkomst" en probeer te loggen stap voor stap totdat ik bij de service ben ..

Afgezien daarvan ik vind samba een irritatie om te configgen, ik heb dus een config gejat van een synology

[Hero of Time]

vso schreef op zondag 14 augustus 2016 @ 23:07:
[...]

Jup

Daarom begin in bij "binnenkomst" en probeer te loggen stap voor stap totdat ik bij de service ben ..

Afgezien daarvan ik vind samba een irritatie om te configgen, ik heb dus een config gejat van een synology

De grootste grap met Samba vind ik dat mensen er zo veel problemen mee hebben, maar wat ik met een paar kleine aanpassingen aan de standaard share die er staat (of die in comments) al een werkende share heb. Enige wat ik verander is de security setting. Weet niet meer wat de standaard, maar van user naar share of andersom iig. Een enkele keer heb ik met smbpasswd moeten werken om een user te maken of inschakelen, maar dat was 't wel.

[vso]

Hero of Time schreef op zondag 14 augustus 2016 @ 23:26:
[...]

De grootste grap met Samba vind ik dat mensen er zo veel problemen mee hebben, maar wat ik met een paar kleine aanpassingen aan de standaard share die er staat (of die in comments) al een werkende share heb. Enige wat ik verander is de security setting. Weet niet meer wat de standaard, maar van user naar share of andersom iig. Een enkele keer heb ik met smbpasswd moeten werken om een user te maken of inschakelen, maar dat was 't wel.

Hmm zeker nog niet gestoeid met windows domain(s) en diverse windows versies .. allemaal in 1 netwerk .:)

[Hero of Time]

vso schreef op maandag 15 augustus 2016 @ 09:16:
[...]

Hmm zeker nog niet gestoeid met windows domain(s) en diverse windows versies .. allemaal in 1 netwerk .:)

Ik heb er wel eens in zo'n situatie mee gewerkt, maar dat was een read-only share dat gewoon open stond voor iedereen. Voor de rest thuis ingesteld en dat is nooit zo spannend.

De share die ik nu op m'n computer aan heb staat is voor VMs zo te zien en ik heb 'security = share' ingesteld.

code:

[share]
    path=/media/share
    browseable = yes
    read only = yes
    writeable = no
    guest ok = yes

En dat werkt prima voor read only. Beetje tweaken en het is ook gewoon schrijfbaar.

[CAPSLOCK2000]

Hero of Time schreef op zondag 14 augustus 2016 @ 23:26:
De grootste grap met Samba vind ik dat mensen er zo veel problemen mee hebben, maar wat ik met een paar kleine aanpassingen aan de standaard share die er staat (of die in comments) al een werkende share heb. Enige wat ik verander is de security setting. Weet niet meer wat de standaard, maar van user naar share of andersom iig. Een enkele keer heb ik met smbpasswd moeten werken om een user te maken of inschakelen, maar dat was 't wel.

De ironie is dat Samba vaker beter met zichzelf compatible is dan Windows zelf. Het protocol gaat al erg lang mee en er zijn heel veel varianten en aanpassingen. Bij iedere nieuwe Windows-versie verandert er ook iets aan SMB. Samba heeft altijd geleeft in een wereld waarin de meerderheid van de andere systemen op een ander OS draait (Windows). Windows is daarintegen opgegroeid in een wereld waar de meerderheid van systemen hetzelfde OS draait, vaak nog dezelfde versie ook. Compatible zijn zit daarom diep in het bloed van Samba. Helaas is er geen "one size fits all" oplossing. Windows 10 systemen laten samenwerken met Windows 95 systemen (om het even lekker extreem te nemen) is ook onder Windows moeilijk.

Misschien speelt het ook een rol dat mensen die voor het eerst Samba opzetten meestal net zijn overgestapt van Windows naar Linux. Niet alleen Samba is nieuw maar de hele omgeving en de manier van werken ook. Vaak zijn het mensen die nog geen 10 jaar ervaring in de IT hebben maar nog aan het begin van hun pad staan, los van het OS.

[vso]

CAPSLOCK2000 schreef op maandag 15 augustus 2016 @ 16:50:
[...]


De ironie is dat Samba vaker beter met zichzelf compatible is dan Windows zelf. Het protocol gaat al erg lang mee en er zijn heel veel varianten en aanpassingen. Bij iedere nieuwe Windows-versie verandert er ook iets aan SMB. Samba heeft altijd geleeft in een wereld waarin de meerderheid van de andere systemen op een ander OS draait (Windows). Windows is daarintegen opgegroeid in een wereld waar de meerderheid van systemen hetzelfde OS draait, vaak nog dezelfde versie ook. Compatible zijn zit daarom diep in het bloed van Samba. Helaas is er geen "one size fits all" oplossing. Windows 10 systemen laten samenwerken met Windows 95 systemen (om het even lekker extreem te nemen) is ook onder Windows moeilijk.

Misschien speelt het ook een rol dat mensen die voor het eerst Samba opzetten meestal net zijn overgestapt van Windows naar Linux. Niet alleen Samba is nieuw maar de hele omgeving en de manier van werken ook. Vaak zijn het mensen die nog geen 10 jaar ervaring in de IT hebben maar nog aan het begin van hun pad staan, los van het OS.

Hmmm ja/nee misschien
Wat je wellicht beter bedoelt met samba compatibiliteit: Windows zegt er is maar 1 juiste manier, het kan wel anders (maar stiekem toch niet en veel issues als resultaat) .. terwijl Linux gewoon flexibeler is dan zelfs de guru's weten.. (Doom spelen op een linux kernel die draait op een HP laserprinter, probeer dat eens met windows )

Windows is niet lastig en samba ook niet als je ze qua moeilijkheid vergelijkt. Alleen je moet Samba aanpassen op Windows en niet andersom .. (reghacks, AD aanpassingen etc..is een no go)
Wat extra helpt is dat je de per variatie een IP subnet mikt..omdat je dan samba per IP verder kan tunen ..
Tot windows 10 is er eigenlijk geen aanpassing aan windows nodig. Of je nu in domain of in workgroup of losse clients draait.. (same username + password) lost al 99% van je isssues op, sterker nog veel van deze "hack" gebruikt gemaakt in dmz/losse servers / clients.

Windows 10 is nog steeds niet lastig, als je rekening houd dat ipv6, fw, en smb3 wat roet in het eten kan gooien .. en hier is perfect omheen te werken, de 3 gewoon tijdelijk uitzetten en 1 voor 1 weer aan nadat je het werkend hebt..

Wat niet echt helpt is dat veel howto's en guide's je verwijzen zoals eerder genoemde reghack's AD aanpassingen enzv laten doen.. terwijl dit geheel overbodig is.

Wat overgens wel intressant is (nog nooit getest) is dat er projecten zijn zoals puppet(linux) <--> DSC(windows eqv) en GPO voor linux/windows (verschillen uiterraard iets) .. en nog paar van die intressante intergraties .. zoals AD groepen/rechten/users.. (en meer) Samba kan ook zeer groot gedeelte voor win Domain Controler spelen dacht ik.
https://wiki.samba.org/in...ributed_File_System_(DFS) is zeer intressant omdat je letterlijk nodeloos (lees node onafhankelijk) je cifs/smb/samba share op kan zetten.

Samba presteert beter als een Windows Fileserver .. maar dat ligt eerder aan het onderliggende OS dan aan de filesharing technieken..

[Christian_Ku]

Zo, nog even de resultaten laten zien is wel zo netjes hier!

Na het even wat drukker gehad te hebben van de week weer eens naar mijn RPi gekeken en inderdaad het hele Samba share tussen mijn beide RPi's laten varen en meteen voor NFS gegaan. Na wat packages geinstalleerd te hebben wees het zich eigenlijk allemaal vanzelf. Werkte meteen. Dank iedereen, deze kan op slot.