Jak sprawić, by samba podążał za dowiązaniem symbolicznym poza wspólną ścieżką

61

To jest serwer Ubuntu 10.04 64 i samba 3.4.7.

Mam wspólny katalog /home/mit/sharei inny /home/temp, do którego linkuję:

ln -s /home/temp /home/mit/share/temp

Ale w S:/tempsystemie Windows po użyciu Internetu nie mogę otworzyć , ale w systemie Linux można uzyskać dostęp /home/mit/share/tempzgodnie z oczekiwaniami.

Działa to, jeśli podlinkuję katalogi wewnątrz /home/mit/share/temp, więc myślę, że samba ogranicza przeskakiwanie z linkiem na zewnątrz / powyżej katalogu współdzielonego.

EDYTOWAĆ:

Zobacz także to pytanie zatytułowane Ubuntu + najnowsza wersja samby, dowiązania symboliczne nie działają już na udziale zamontowanym w systemie Windows .

Najlepiej wydaje się umieszczenie unix extensions = now sekcji globalnej follow symlinks = yesi wide links = yestylko w sekcji akcji, gdzie jest to naprawdę potrzebne.

unix extensionFlaga musi żyć w sekcji globalnej, a nie w poszczególnych sekcjach akcji. Ale ze względów bezpieczeństwa lepiej jest korzystać z innych opcji tylko tam, gdzie jest to potrzebne, a nie globalnie.

— mit
źródło

Czy możesz wypróbować hardlink zamiast dowiązania symbolicznego?

— Falmarri

92

Edytuj plik smb.conf

[global]
unix extensions = no

[share]
follow symlinks = yes
wide links = yes

Uwaga: Jeśli używasz nowszej wersji samby, mogą działać dla Ciebie następujące czynności:

[global]
allow insecure wide links = yes

[share]
follow symlinks = yes
wide links = yes

dokumentacja follow symlinksi wide linksflagi: https://www.samba.org/samba/docs/using_samba/ch08.html#samba2-CHP-8-TABLE-1

— Mahesh
źródło

Zobacz także wyjaśnienie na końcu powyższego pytania, dlaczego jest to dobre rozwiązanie.

— mit

Na wypadek, gdyby ktoś zmagał się z wszystkimi komentarzami zaciemniającymi ten raczej krótki plik: skopiuj do kopii zapasowej i ponownie utwórz cp /etc/samba/smb.conf /etc/samba/smb.conf.bakgrep -o '^[^#;]*' smb.conf.bak >smb.conf

— filtr

ma [share]na myśli [<share_name>]?

— Necktwi,

@neckTwi - właśnie to założyłem i zadziałało dla mnie.

— Geoff,

@Geoff To nie działało dla mnie! przełączono nasshfs

— Necktwi

11

Pozdrowienia, próbowałem wprowadzić tę konfigurację, aby naprawić dowiązania symboliczne dla systemu Windows dla mojej instalacji, ale nie jestem pewien, czy wpłynie to na klienta Windows, w przeciwnym razie po podłączeniu do tego pola będzie podążać za dowiązaniami symbolicznymi.

[global]                                                                        
unix extensions = no

— Qiqi
źródło

Odpowiedź Qiqi zgadza się z tą: superuser.com/questions/128716/…

— Janus

Tak, to zdecydowanie rozwiązuje problem w moim środowisku.

— TML

10

Alternatywnie do innych odpowiedzi, aby utrzymać włączone rozszerzenia unix, można użyć:

[global]
allow insecure wide links = yes

[share]
follow symlinks = yes
wide links = yes

— użytkownik1182474
źródło

ma [share]na myśli [<share_name>]?

— Necktwi,

Tak, może to być dowolna sekcja smb.conf, która „opisuje udostępniony zasób (znany jako„ udział ”)” (cytowany z dokumentacji). Może być także w specjalnej sekcji [homes], w której go używam. Szczegółowe informacje można znaleźć w dokumentacji .

— user1182474,

4

Aby umożliwić klientom Samby śledzenie dowiązań symbolicznych poza wspólną ścieżką, wszystko, czego potrzebujesz w konfiguracji Samby, to:

[global]
allow insecure wide links = yes
unix extensions = no

[myShare]
wide links = yes

(oprócz samych definicji Samby, oczywiście). To - teoretycznie - wystarcza dla klientów * nix.

Uwaga: Dyrektywa „podążaj za dowiązaniami symbolicznymi” nie jest konieczna, ponieważ domyślnie ustawiona jest na „tak”

Jeśli chodzi o klientów Windows, nadal brakuje 1 ustawienia, aby umożliwić im podążanie za takimi linkami. Aby to zrobić:

otwórz powłokę systemu Windows mającą uprawnienia administratora

biegać :

fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1

uruchom ponownie, aby ponownie załadować ustawienia

Uwaga: ten sam wynik można uzyskać, edytując rejestr systemu Windows. Zobacz linki poniżej

źródła:

— Httqm
źródło

0

Jeśli korzystasz z AppArmor, może być konieczne zajęcie się czymś więcej niż tylko plikiem konfiguracyjnym Samby.

Potrzebne są następujące dyrektywy smb.conf:

follow symlinks = yes
wide links = yes
unix extensions = no
# No need for "allow insecure wide links" unless you want "unix extensions = yes"

Ale AppArmor blokuje dostęp do części systemu plików zgodnie z własną semantyką zestawu reguł. Tak więc, jeśli twoje dowiązanie symboliczne w Sambie wskazywało na lokalizację, którą AppArmor zablokowałby, Samba odmówiłaby dostępu.

W moim systemie Samba aktualizuje profile AppArmor przy uruchamianiu / zatrzymywaniu usługi, abym mógł zmienić profil AppArmor, ale ryzykuję zastąpienie go przez Sambę lub inny program. Zamiast tego postanowiłem utworzyć niedostępny udział w Sambie, odwołując się do lokalizacji zawierającej cel dowiązania symbolicznego, do którego chciałem uzyskać dostęp (nadal w smb.conf):

# The following is a hack for AppArmor to allow the path
[share1 for AppArmor] # Or whichever name you choose
    browseable = no
    path = /home # Point to directory or parent directory of the location to access
    read only = yes
    guest ok = no
    valid users = none

— palswim
źródło