Pfad nicht verfügbar

german

#1

Hallo,

wir haben nach dem Reboot eines Fileservers das Problem, dass manche Benutzer, die im Explorer auf Downloads klicken, folgende Fehlermeldung erhalten:

Der besagte Pfad existiert jedoch und die Berechtigungen stimmen auch.
Hier die Berechtigungen von einem Problemuser (gsell) und einem User, bei dem alles funktioniert (martinetz):

[code]root@s-vucs04:/var/daten/profileRedirection# getfacl gsell/

file: gsell/

owner: gsell

group: Domain\040Users

user::rwx
user:gsell:rwx
group::r-x
group:Domain\040Users:r-x
group:Geschaeftsleitung:r-x
mask::rwx
other::r-x
default:user::rwx
default:user:gsell:rwx
default:group::r-x
default:group:Domain\040Users:r-x
default:group:Geschaeftsleitung:r-x
default:mask::rwx
default:other::r-x

root@s-vucs04:/var/daten/profileRedirection# getfacl martinetz/

file: martinetz/

owner: martinetz

group: Domain\040Users

user::rwx
user:martinetz:rwx
group::r-x
group:Domain\040Users:r-x
group:Geschaeftsleitung:r-x
mask::rwx
other::r-x
default:user::rwx
default:user:martinetz:rwx
default:group::r-x
default:group:Domain\040Users:r-x
default:group:Geschaeftsleitung:r-x
default:mask::rwx
default:other::r-x
[/code]

Schließlich noch der LDAP-Eintrag von der Freigabe:

[code]root@s-vucs00:~# univention-ldapsearch cn=profileRedirection

extended LDIF

LDAPv3

base <dc=koller,dc=local> (default) with scope subtree

filter: cn=profileRedirection

requesting: ALL

profileRedirection, s-vucs04.koller.local, shares, koller.local

dn: cn=profileRedirection,cn=s-vucs04.koller.local,cn=shares,dc=koller,dc=loca
l
univentionShareNFSSync: sync
univentionShareSambaForceDirectoryMode: 0700
cn: profileRedirection
objectClass: top
objectClass: univentionShare
objectClass: univentionShareSamba
objectClass: univentionShareNFS
objectClass: univentionObject
univentionShareWriteable: no
univentionShareSambaForceSecurityMode: 00
univentionShareSambaLocking: 1
univentionShareSambaForceDirectorySecurityMode: 00
univentionShareSambaMSDFS: no
univentionShareSambaCreateMode: 0700
univentionShareSambaWriteable: yes
univentionShareSambaInheritPermissions: no
univentionShareSambaBrowseable: no
univentionShareSambaHideUnreadable: no
univentionShareSambaInheritAcls: 0
univentionShareSambaPublic: no
univentionShareSambaSecurityMode: 0777
univentionShareDirectoryMode: 0770
univentionShareSambaBlockingLocks: 1
univentionSharePath: /var/daten/profileRedirection
univentionShareSambaDirectorySecurityMode: 0777
univentionShareSambaLevel2Oplocks: 1
univentionShareSambaNtAclSupport: 1
univentionShareSambaCscPolicy: manual
univentionShareSambaForceCreateMode: 0700
univentionObjectType: shares/share
univentionShareSambaOplocks: 1
univentionShareSambaDirectoryMode: 0700
univentionShareSambaFakeOplocks: 0
univentionShareGid: 0
univentionShareNFSRootSquash: no
univentionShareSambaDosFilemode: no
univentionShareSambaStrictLocking: 0
univentionShareSambaName: profileRedirection
univentionShareNFSSubTree: no
univentionShareSambaInheritOwner: no
univentionShareUid: 0
univentionShareHost: s-vucs04.koller.local

search result

search: 3
result: 0 Success
[/code]

Hat jemand eine Idee?

TIA


#2

Kann der Fileserver mit seinem DNS Namen gepingt werden?


#3

Eine sehr gute Frage.
Ja, kann er - allerdings funktioniert der Download-Ordner plötzlich, wenn man in der Freigabe statt des Servernamens die IP-Adresse oder den FQDN eintippt.

Ich werde den Terminalserver heute Abend neu starten - ich vermute, dass das Problem dann weg ist.


#4

[quote=“roland.gsell”]…allerdings funktioniert der Download-Ordner plötzlich, wenn man in der Freigabe statt des Servernamens die IP-Adresse oder den FQDN eintippt.
[/quote]

das klingt irgendwie nach dieser Windows-Beschränkung, die immer nur pro Zielhost einen Benutzernamen zulässt. Will man einen anderen Benutzernamen verwenden, musste man die IP-Adresse nehmen.
Wobei ich mir nicht sicher bin, ob dies in aktuellen Windows-Versionen immer noch so ist. Dieses Wissen stammt gefühlt noch aus NT-Zeiten.

Viele Grüße,
Dirk Ahrnke


#5

Das Problem ist wieder aufgetaucht.

Nachdem wir festgestellt haben, dass der FQDN funktioniert haben wir die Freigabe entsprechend geändert. (per GPO)
Ein paar Tage später ruft der Kunde wieder an und sagt es geht wieder nicht.

Kurioserweise ist nun das Verhalten genau umgekehrt:
Wenn man den FQDN wieder durch den kurzen Namen ersetzt, geht es wieder.

Kann man GPOs per cronjob alle paar Tage hin- und her wechseln?
… Scherz beseite, was könnte da schief laufen? Ich bin ratlos.


#6

Hast Du schon mal nachgesehen, ob nicht doch aus irgendeinem Grund, z.B. durch ein lokales Mapping oder eine Batch Laufwerke oder anderweitige Zugriffe auf die Freigabe kollidieren.
Zum Beispiel durch hart kodierte Nutzernamen in einer Applikation/einem Skript.