john-doe
Goto Top

SMB1 Proxy auf Debian 11.7 nur Leserecht

Hallo Leute
Es ist mal wieder so weit, ich benötige einen kleinen Gedankenanstoß

Aufgabenstellung: Alte Maschinenrechner mit Windows XP müssen auf ein Server 2022 Fileshare zugreifen.
SMB1 aktivieren ist am Fileserver KEINE Option!
Daher werden wir für die Anbindung der Maschinen einen SMB1 Proxy einsetzen.
Habe dazu einige Anleitungen gefunden. Unter anderem:

https://sysadmon.eu/smb1-proxy-fuer-unsichere-netzwerke/

https://andys-tech.blog/2022/03/separate-your-smbv1-only-systems-with-an ...

So weit so gut: Debian 11.7 runtergeladen, installiert und gemäß der Anleitungen eingerichtet.
Zugriff auf das Proxy-Share funktioniert - Leider aber nur lesend.
Vom Debian aus kann ich problemlos in das gemountete Share des 2022er Server schreiben.
Wenn ich mit den selben SMB-Einstellungen ein lokales Share am Debian erstelle, kann ich von einem SMB 1 Client aus darauf lesen und schreiben.

Auf das Proxyshare funktioniert einfach nur lesen ... warum auch immer ..

Auch mit der Brechstange mal chown und chmod auf dem SMB Mount am Debian läuft fehlerfrei durch, kann scheint aber nicht zu wirken.


Hat jemand eine Idee um den "Schreibschutz" weg zu bekommen


Danke Jonny


PS: Nachdem es sich aktuell nur mal um eine Testmaschine handelt, verzeiht mir die Namensgebungen ;)
smb.conf
fstab

Content-Key: 7376334509

Url: https://administrator.de/contentid/7376334509

Printed on: April 27, 2024 at 22:04 o'clock

Member: Th0mKa
Th0mKa May 31, 2023 at 20:28:46 (UTC)
Goto Top
Moin,

die Freigabe- und NTFS Berechtigungen für den Proxy User erlauben schreiben auf dem Win2022 Server?
Das mit dem "usershare allow guests = yes" würde ich auch nicht machen.

/Thomas
Member: john-doe
john-doe May 31, 2023 at 20:40:12 (UTC)
Goto Top
Hallo Thomas

Danke für dein Kommentar!
Ja, die Berechtigungen auf der Windows Seite passen sicher, wie gesagt vom Debian aus kann ich problemlos auf gemountete Share schreiben.

"usershare allow guests = yes" danke, werd ich mir genauere ansehen.

LG Jonny
Member: commodity
commodity May 31, 2023 at 21:24:44 (UTC)
Goto Top
Ich würde auch bei den Berechtigungen ansetzen.

Du hast ja im Prinzip drei User im Spiel. Den der das Share vom Server mountet, den User für den Client und den dafür eingerichteten SMB-User.
Vom Debian aus kann ich problemlos in das gemountete Share des 2022er Server schreiben.
Das sieht doch so aus, als ob der mountende User Schreibrechte auf dem Server hat.
Jetzt braucht noch der für den Client eingerichtete Linux-User (bei Dir: "proxy-access-user")Schreibrechte an der Freigabe. Hast Du diesen Schritt beachtet?
chown -Rv proxy-access-user:proxy-access-user /mnt/fileserver
Das hier
Auch mit der Brechstange mal chown und chmod auf dem SMB Mount am Debian läuft fehlerfrei durch, kann scheint aber nicht zu wirken.
klingt ja so.

Aber hast Du auch einen berechtigten SMB-User für den proxy-access-user angelegt, also für den User, den der Windows-Client für den Zugriff benutzt?
https://wiki.ubuntuusers.de/Samba_Server/#Benutzerverwaltung
Samba hat in der Standardinstallation eine vom System getrennte Benutzerverwaltung, welche mit dem Befehl smbpasswd administriert wird...
Benutzer, die zur Datenbank von Samba hinzugefügt werden, müssen schon auf dem System als "normale" Benutzer vorhanden sein. Es ist möglich, aber nicht erforderlich, für Samba das gleiche Passwort wie das Systempasswort des Benutzers zu nehmen.
Wenn das nicht der Fall ist, greifst Du evtl. mit Deinem Windows derzeit als "Gast" auf die Freigabe zu. Daraus folgt dann (aus dem Link oben):
screenshot 2023-05-31 231714

Viele Grüße, commodity
Member: john-doe
Solution john-doe Jun 01, 2023 at 14:12:44 (UTC)
Goto Top
Hallo Leute, danke für Eure Inputs. Wir haben es nun lösen können. Das Problem war das Usermapping im Share
force group = smbproxy, force user = smbproxy

Da es möglicherweise für den einen oder anderen durchaus interessant sein kann, habe ich eine neue angepasste und funktionierende Anleitung auf Basis von Debian 11.7 erstellt:

#Erläuterung der User:
User bei der Installation von Debian: smbproxy
User für Zugriff auf Share vom SMB-Proxy: smb-user
User für Zugriff auf Fileserver: svc_smbproxy

#Pakete installieren
apt install samba cifs-utils

#Mounten des SMB Shares vom tatsächlichen Fileserver
nano /etc/fstab
//10.xx.xx.xx/Maschinendaten /mnt/fileserver cifs user,uid=1000,gid=1000,vers=3.11,credentials=/etc/smbproxycred,auto 0 0

#Anlegen und speichern der Userdaten für Zugriff auf Fileserver
nano /etc/smbproxycred
username=svc_smbproxy
password=123456
domain=firma.local


#Anlegen eines eigenen User für den SMB Zugriff auf den SMB-Proxy
adduser smb-user
usermod smb-user --shell /usr/sbin/nologin
smbpasswd -a smb-user


#Umbennen der originalen smb.conf
mv /etc/samba/smb.conf /etc/samba/smb.conf.orig

#Erstellen einer smb.conf mit untenstehendem Inhalt
nano /etc/samba/smb.conf

###beginn smb.conf###

[global]
lanman auth = Yes
load printers = No
log file = /var/log/samba/log.%m
logging = file
map to guest = Bad User
max log size = 1000
ntlm auth = Yes
obey pam restrictions = No
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
server min protocol = NT1
server role = standalone server
server string = %h server (Samba)
unix password sync = Yes
usershare allow guests = No
wins support = Yes
idmap config * : backend = tdb
browseable = Yes
case sensitive = No
ea support = No
map archive = No
store dos attributes = No

### Freigabe ####

[Maschinendaten]
browseable = Yes
create mask = 0777
directory mask = 0777
force create mode = 0777
force directory mode = 0777
force group = smbproxy
force user = smbproxy
path = /mnt/fileserver
valid users = smb-user @smb-user
write list = smb-user @smb-user


###ende smb.conf####


#Maschine neu starten
reboot

#Mount einbinden
mount -a

#Zugriff auf Fileserver kontrollieren
ls /mnt/fileserver


#Automatische Einbindung nach Reboot. Der alleinige mount in fstab ist nicht zuverlässig nach einem Neustart
crontab -e
@reboot sleep 60 && mount -a
update-rc.d cron defaults