Ich habe auf dem UCS 5.2.6 eine Freigabe eingerichtet, Diese soll einem Debian Trixie Client, der nicht in die Domäne eingebunden ist, bereitgestellt werden.
Das mounten auf dem Cllient schlägt fehl:
mount -t nfs4 ServerIP:/nfs /mnt/nfs
mounting 192.168.3.24:/nfs failed, reason given by server: No such file or directory
showmount -e ServerIP liefert
mounting 192.168.3.24:/nfs failed, reason given by server: No such file or directory
Die Ports sind vom Client aus erreichbar.
Die Services auf dem Server laufen.
Ein “-t nfs4” ist auch nicht mehr notwendig. Trotzdem sollte es auch “mit” funktionieren".
wie du siehts schreibt der Server kein “denied” sonder das es diese angeforderte Freigabe nicht gibt.
showmount -e ServerIP liefert
mounting 192.168.3.24:/nfs failed, reason given by server: No such file or directory
Das hätt ich so jetzt noch nie gesehen. Bitte mach nochmal ein “showmount -e <serverIP>” von deinem Client aus und poste die Ausgabe.
Auch ein “exportfs -v” direkt am NFS-Server wäre interessant.
Bitte benutze auch die Formatierungsmöglichkeiten, damit können wir Beiträge viel leichter lesen.
Server läuft:
root@fileserver:~# systemctl status nfs-server
nfs-server.service - NFS server and services
Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; preset: enabled)
Drop-In: /run/systemd/generator/nfs-server.service.d
└─order-with-mounts.conf
Active: active (exited) since Mon 2026-09-07 05:54:27 CEST; 23h ago
Process: 837 ExecStart=/usr/sbin/rpc.nfsd (code=exited, status=0/SUCCESS)
Main PID: 837 (code=exited, status=0/SUCCESS)
CPU: 6ms
Sep 07 05:54:25 fileserver systemd[1]: Starting nfs-server.service - NFS server and services…
Sep 07 05:54:27 fileserver systemd[1]: Finished nfs-server.service - NFS server and services.
Firewall auf dem Client ist aus:
root@terra:~# systemctl status ufw
ufw.service - Uncomplicated firewall
Loaded: loaded (/usr/lib/systemd/system/ufw.service; enabled; preset: enabled)
Active: inactive (dead) since Tue 2026-09-08 05:41:21 CEST; 3s ago
Duration: 35min 40.419s
Invocation: 4783218d97a54e41b35a1bd75690c76e
Docs: man:ufw(8)
Process: 7283 ExecStop=/usr/lib/ufw/ufw-init stop (code=exited, status=0/SUCCESS)
Main PID: 914 (code=exited, status=0/SUCCESS)
Mem peak: 2M
CPU: 491ms
showmount -e IP_Server liefert:
rpc mount export: RPC: Unable to receive; errno = Connection refused
über Ping ist der Server erreichbar Test nmap vom Client:
Starting Nmap 7.95 ( https://nmap.org ) at 2026-09-08 05:57 CEST
Nmap scan report for IP-Server
Host is up (0.0028s latency).
PORT STATE SERVICE
111/tcp open rpcbind
MAC Address: BC:24:11:21:B9:E4 (Proxmox Server Solutions GmbH)
Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds
Test nmap nmap -p2049 -PN vom Client
Starting Nmap 7.95 ( https://nmap.org ) at 2026-09-08 05:59 CEST
Nmap scan report for IP-Adresse
Host is up (0.0027s latency).
PORT STATE SERVICE
2049/tcp open nfs
MAC Address: BC:24:11:21:B9:E4 (Proxmox Server Solutions GmbH)
Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds
Auf dem Domänencontroller sieht die Freigaben so aus:
Hmm, sieht jetzt eigentlich ok aus. Nmap sagt die Ports auf dem NFS-Server sind offen. Und ja ich mounte auch auf Proxmox NFS, und auch Sambafreigaben von UCS.
Was sagt denn das Kommando direkt am UCS NFS-Server? Geht das überhaupt?
Danke für die schnelle Reaktion.
Ich bin jetzt in der Firma. Testen kann ich erst wieder, wenn ich im Homeoffice bin. Die Installation läuft da auf einem gesonderten Server.
Zur Zeit in der Anlage:
UCS Domäne
UCS Backp-Controller
UCS Mailserver
UCS Fileserver
Guten Morgen,
ich bin jetzt ein Stück weiter. Ich habe auf dem Domänencontroller auch noch eine Freigaben eingerichtet.
Diese reagiert wie gewünscht.
Es muss also am Fileserver selbst liegen und der Installation der Rolle Windows-kompatibler Memberserver.
Ich werde die Rolle zunächst deinallieren und dann wieder installieren.
Deinstallation und Installation durchgeführt.
Auf dem Domänencontroller die Freigaben auf dem Fileserver gelöscht
Auf dem Fileserver unter freigaben verbliebenen Verzeichnisse gelöscht
Auf dem Domänencontroller neu angelegt
Auf dem Fileserver überprüft - Verzeichnis nicht vorhanden
Rolle auf dem Fileserver wieder deinstalliert
AH ich kann vom Domänencontroller über das APP Center den Windows kompatilben Memberserver nicht installieren. Der fehlt in der Liste. Kann das ein Grund sein?
Muss zugeben das meine letzte Installation schon recht lange her ist. Aber wenn ich mich erinnere funktionierte das immer alles recht klaglos. Die Rollen/Funktionen usw. hab ich immer vom Appcenter aus installiert.
Leider hab ich aktuell keine Zeit das ich mir eine frische UCS Umgebung installiere und teste. Vielleicht findet sich ja jemand anders der das hier testen möchte?
Wäre auf jeden Fall sehr interessant wie es sich verhält.
beide Server haben:
Die momentan installierte Version ist 5.2-6 errata606.
Die Meldungen sind identisch
Fileserver
nfs freigabe eingerichtet von domanenen-controller
freigaben wird angelegt
vom Client showmount -e
rpc mount export: RPC: Unable to receive; errno = Connection refused
Domänencontroller
Active Directory kompatibler installiert
vom Client showmount - e
rpc mount export: RPC: Unable to receive; errno = Connection refused
Port Scans
vom Client aus
root@CB08-PC:~# nmap -p111 -PN IP-Adresse
Starting Nmap 7.95 ( https://nmap.org ) at 2026-09-14 13:17 CEST
Nmap scan report for IP-Adresse
Host is up (0.00076s latency).
PORT STATE SERVICE
111/tcp open rpcbind
MAC Address: xx:xx:xx:xx:xx:xx (Proxmox Server Solutions GmbH)
Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds
root@CB08-PC:~# nmap -p2049 -PN IP-Adresse
Starting Nmap 7.95 ( https://nmap.org ) at 2026-09-14 13:17 CEST
Nmap scan report for IP-Adresse
Host is up (0.00071s latency).
PORT STATE SERVICE
2049/tcp open nfs
MAC Address: xx:xx:xx:xx:xx:xx (Proxmox Server Solutions GmbH)
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
auf dem Fileserserver ausgeführt
ucr get security/packetfilter/package/univention-nfs/tcp/111/all
ucr get security/packetfilter/package/univention-nfs/tcp/2049/all
Showmount -e vom Client
rpc mount export: RPC: Unable to receive; errno = Connection refused
auf dem Fileserver
systemctl stop univention-firewall
showmount -e vom Client
Export list for IP-Adresse:
/freigaben/nfs-3 *
/freigaben/nfs 192.168.xxx.0/24
Das entspricht auch den Einstellungen in den Freigaben
Es ist die Firewall. Ich muss mal schauen, ob ich in den Einstellungen Portumleitungen finde, wenn der Dienst läuft.
Wenn ich das jetzt richtig verstehe, läuft der Verbindungsaufbau so ab:
der Client fragt auf Port 111 wo der Port von mountd liegt.
dann antwortet der Server
IPTables auf dem Fileserver liefert mit iptables -L
Diese Ports sind geschlossen und dynamisch.
Ich muss jetzt rauskriegen, wie diese Port fest mountd, statd und lockd gebunden werden und dann feste in IPTABLES hinterlegen.
Deshalb funktioniert es auch, nachdem univention-firewall gestoppt wurde.
Vielen Dank für deinen ausführlichen Bericht. Ich hab das jetzt auch nochmal schnell getestet. Frische UCS 5.2 Installation.
primary directory node mit Active Directory-kompatibler und Keycloak (bestehende Testsystem)
managed node → frisch installiert und der Domäne hinzugefügt. Apps: Windows kompatibler Memberserver (ist aber wohl nicht notwendig, da laut Liste nur Samba Pakete installiert werden)
Freigabe über die WebUI erstellt: /home/supertux showmount bringt auch bei mir am Client dieselbe Fehlermeldung.
Aber ein Mount mit folgendem Kommando vom Client (Kubuntu 26.04) aus funktioniert ohne jeglicher Modifikation:
sudo mount 192.168.32.6:/home/supertux /mnt/temp
Die Freigabe wurde automatisch mit NFS Version 4.2 gemountet.
Aber bei meiner bestehenden produktiven Domäne zeigt showmount vom Client aus, alles sauber an. Univention Firewall läuft und beide Server haben die gleichen Firewallregeln, zumindest laut UCR. Strange.
ucr get security/packetfilter/package/univention-nfs/udp/111/all
ACCEPT
ucr get security/packetfilter/package/univention-nfs/udp/111/all/en
portmap
UDP und TCP sind offen. Mit nmap geprüft.
IPTABLES hab ich mir jetzt nicht im Detail angesehen.
Wobei “rpcinfo -p” am produktiven System so aussieht: