Come mantenere in modo affidabile la condivisione di rete connessa per un utente specifico mediante automount?


2

Ho un Synology NAS e un Mac mini con Plex e XBMC, che trasmettono contenuti dal NAS. MM perde frequentemente la connessione al NAS, per diversi motivi (ad esempio dopo l'aggiornamento / riavvio del NAS, problemi di rete, problemi OS X).

Dopo aver provato diverse soluzioni per questo problema, ho finalmente trovato lo strumento automount integrato, che dovrebbe ricollegare le unità di rete quando la connessione viene persa. L'ho installato e sembrava funzionare. Ma c'è un problema fastidioso:

Non sono sicuro di come esprimerlo, ma le condivisioni autoportate sembrano entrare di volta in volta in uno stato di non-realmente-connesso. Quando la condivisione viene attraversata, si connette immediatamente. Va bene, ma la condivisione è montata solo per l'utente che ha effettuato l'accesso .

Ho due account utente: TV, che esegue Plex e XBMC e deve accedere alla condivisione e Admin, che utilizzo per le attività di gestione. Occasionalmente, uso l'account Admin per connettermi anche al NAS, ma sto usando il Finder per questo. Non c'è bisogno di una connessione permanente.

Per qualche ragione non capisco, a volte, la condivisione autoportata è montata per l'account Admin. Il che significa che l'account TV non è in grado di accedere alla condivisione (Autorizzazione negata). io posso umount la condivisione con Admin e ls con TV per montarlo per quest'ultimo, ma dopo un po 'di tempo, l'amministratore ha di nuovo le autorizzazioni.

Come posso risolvere questo? Come devo impostare le autorizzazioni in modo che la TV sia l'unico account che può accedere alla condivisione autosommossa?

Ecco come appaiono i miei file automount:


auto_master

permessi: -rw-r--r-- 1 root wheel

+auto_master      # Use directory service
/net              -hosts     -nobrowse,hidefromfinder,nosuid
/home             auto_home  -nobrowse,hidefromfinder
/Network/Servers  -fstab
/-                -static
/-                auto_nas   -nosuid,noowners


auto_nas

permessi: -rw------- 1 root staff

/NAS -fstype=smbfs,soft smb://TV:@192.168.1.56/Files


/ NAS (il punto di mount)

permessi: drwx------@ 1 TV wheel


MM sta eseguendo Yosemite (10.10.3).

Risposte:


1

Supponendo che NON si desideri abilitare la funzionalità di accesso utente "root" e allentare le autorizzazioni di file e directory abbastanza da aprire potenzialmente il sistema a un vettore di attacco di sicurezza significativo (e presumo esattamente che ...), ad oggi, 7 febbraio 2017, non c'è modo di realizzare ciò che descrivi :(

Almeno non per le condivisioni AFP / SMB / CIFS (quelle sono le uniche tre che ho provato, potresti avere altra fortuna con i volumi NFS ma non li eseguo sulla mia rete quindi non posso confermare).

Sembra che ci siano due potenziali cause alla radice. Uno è che qualche volta intorno a Yosemite, ci sono state alcune modifiche alla differenza tra l'utilizzo della funzionalità di automounting diretto e indiretto che ha causato errori intermittenti quando una condivisione montata automaticamente è stata utilizzata da più di un utente.

A partire da Sierra, questa funzionalità è completamente danneggiata poiché il proprietario della directory speciale / Volumi è stato creato come utente "root" e tale utente assumerà automaticamente la proprietà se a un altro utente viene concessa la proprietà di qualsiasi cartella o file in quella directory. Gli errori sono stati archiviati , sentiti libero di commentare e condividere il tuo oltraggio.

Nel commentare la sezione su questo post del blog discutendo diversi esempi di utilizzo dell'automount (e di alcuni dei suoi limiti) l'utente "Mark" fornisce un'analisi completa di questo problema in relazione alla condivisione di cartelle montate automaticamente su più utenti.

TL; DR: è stato rotto da qualche parte intorno alle 10.10 e nonostante sia stato discusso in molti forum, Apple non ha ancora riconosciuto il bug o si è impegnato in una correzione.

Penso che stia succedendo qualcosa con 10.11 che rompe la procedura & gt; per il montaggio di condivisioni AFP in directory utente. sto provando   per montare afp: // utente: pass@myserver.local/Music su / Users / me / Test

auto_master ha la riga: / - auto_afp -nosuid

auto_afp ha la riga: / Users / me / Test -fstype = afp   afp: // serveuser: servepass@server.local/Music

Il server si monta magnificamente, ma facendo clic sull'icona del server in   / Users / me dà l'errore "La cartella" Test "non può essere aperta perché   non hai il permesso di vedere il suo contenuto. "

Dopo aver risolto il problema, vedo che questo è un permesso   problema. Il punto di montaggio ha il proprietario e il gruppo e le autorizzazioni:   drwx - @ 1 root wheel 364 31 dic 10:01 Test (In realtà, è interessante   - Se svuoto il mio file auto_afp e riavvio, ritorna a   directory normale con proprietario / gruppo / permessi drwx - + 18 me staff 612   31 dic 10:01 Test)

Quindi il problema qui è che autofs sta montando la condivisione con root   privilegio e il mio utente non può effettivamente utilizzare la condivisione. Dalla mia lettura   sul web, questo sembra essere un problema relativamente nuovo - forse El   Capitan in relazione?

Per confronto, quando faccio quanto segue (come utente, non come sistema   utente o usando 'sudo'): Crea una nuova cartella dal Finder a   / Users / me chiamato 'Test3', quindi dal terminale immettere: mount -o nosuid   -t afp afp: // serveuser: servepass@server.local/Music / Users / me / Test3

quindi il server si monta magnificamente (anche se con il nome del cercatore   "Musica", che preferirei cambiare), e ha il seguente   utente / gruppo / permessi: drwx - @ 1 me staff 364 31 dic 10:21 Test3 e   Sono in grado di vedere e manipolare i contenuti.

Quindi, in breve, il problema è: come posso ottenere autofs per montare una rete   Condivisione AFP e mapparlo in una directory utente in modo che l'utente possa accedere   e manipola il suo contenuto? Storicamente, penso che questo sia esattamente   come dovrebbe funzionare Autofs, ma sembra che la proprietà del   cartella mappata da 'root wheel' impedisce ora di essere di qualsiasi reale   uso.

Un'altra questione, mentre ci sono: sono tornato al semplice   obiettivo delineato sopra, ma il mio obiettivo a lungo termine è quello di mappare un esterno   cartella musicale per OGNI utente. auto_afp dovrebbe assomigliare a questo:

/ Users / me / Test -fstype = afp   afp: // serveuser: servepass@server.local/Music / Users / her / Test   -fstype = afp afp: // serveuser: servepass@server.local/Music / Users / him / Test -fstype = afp   afp: // serveuser: servepass@server.local/Music

So che posso fare questo mount negli elementi di login di ciascun utente, ma   non è abbastanza buono per raggiungere i miei bisogni a lungo termine. Lungo   termine, ho bisogno di questa cartella montata all'avvio da autofs per farlo   disponibile per il backup nel cloud.

L'utente "Ben" ha commentato, confermando questa analisi ed echeggiando che almeno dal momento in cui ha condiviso il suo commento, non c'era una soluzione:

Anche l'utilizzo di una mappa indiretta non aiuta. Questa funzionalità sembra   essere fondamentalmente rotto in OSX risalente almeno a Yosemite ... I've   scavato attraverso 3 anni di post di persone che hanno lo stesso problema   e per quanto posso dire, semplicemente non c'è modo di condividere un punto di mount   attraverso gli utenti ... che fallimento enorme, infuriante, incredibile.

Grazie mela!

NOTA: Non lo consiglio a nessuna rete, quindi non fornirò istruzioni dettagliate su come farlo qui, ma un altro utente sulla stessa board di commenti ha indicato che abilitare il login dell'utente root e usarlo per accedere al suo sistema permetterebbe a questo funziona come previsto:

Un'opzione è abilitare root e accedere come root. Una volta che lo fai   tutto inizia a funzionare. Opzione schifo, lo so, ma il mio caso d'uso è un media   server su una rete isolata. L'unica opzione fino a quando non riesco a vedere fino alla mela   lo fa uscire di testa.

Questo è fortemente scoraggiato da tutti, Apple, esperti di sicurezza, ecc. Quindi penso che sia un percorso praticabile attorno a questo problema. Dovremo aspettare che Apple rilasci una correzione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.