Di mana pada sistem file Linux seseorang harus meletakkan media yang dimaksudkan untuk dapat diakses oleh semua akun pengguna?


5

Jika saya memiliki foto, mp3, buku, dan hal-hal lain yang saya ingin semua pengguna dapat mengakses dari direktori umum, di mana pada sistem file Linux saya harus meletakkan direktori itu? Di / usr / share, atau hanya di / usr, atau buat direktori tingkat atas yang baru?

Jawaban:


8

Saya biasanya memasukkan ini /home/media, saya membuat mediagrup unix yang memilikinya dengan sedikit setgid.

Sebagai root, atau menggunakan sudo:

groupadd media
mkdir -p /home/media
chown -R root.media /home/media 
chmod g+s /home/media

Lalu saya menempatkan setiap pengguna yang perlu mengakses data ini dalam mediagrup.

Anda juga dapat menggunakan ACL untuk mengelola hak setiap pengguna untuk direktori.

Anda juga dapat menggunakan /srv/mediajika Anda inginkan, tetapi saya suka rumah untuk dokumen bersama. Apa pun yang masuk /usrharus dihindari untuk ini kecuali Anda berbicara tentang file statis.


1
/ srv adalah tempat yang direkomendasikan oleh FHS: "data spesifik situs yang dilayani oleh sistem ini."
TRS-80

1
atau /optatau /some-madeup-term(fave pribadi saya:) /middleearth. /usr/local(atau bahkan /usr/local/shared) akan baik-baik saja, tetapi tidak ideal. saya tidak suka /homeuntuk tujuan ini karena /homeuntuk direktori pengguna, dan saya menganggap file data di luar ruang lingkup. pada instalasi multiuser sejati, mungkin itu lebih tepat.
quack quixote

1
Saya setuju dengan sebagian besar komentar Anda. Namun, saya tidak setuju dengan /usr/local, yang merupakan subbagian dari /usr, yang imo didedikasikan untuk data statis, hanya-baca. /usr/locallebih mungkin berisi program yang disusun secara lokal atau skrip administrasi. Adapun /srv, saya mendaftar karena sepertinya tempat terbaik menurut FHS, tetapi kemudian untuk data "dilayani oleh sistem ini". Bagi saya, foto, mp3, dll di desktop lebih dari data pengguna, yang milik /home. Mereka tidak benar-benar "dilayani" oleh mesin.
ℝaphink

/usr/local/sharedtidak terdaftar dalam FHS, tetapi ada /usr/local/shareyang setara dengan lokal /usr/share, yang berisi file statis yang digunakan oleh program yang tidak termasuk dalam /usr/lib, jadi itu jelas bukan tempat yang baik untuk memvariasikan data seperti dokumen pengguna imo.
ℝaphink

shareitulah yang saya maksud, oops. itu tergantung pada data dan penggunaan - pada server rumah saya, saya menangani sebagian besar generasi konten, pengguna saya memiliki file, tetapi saya ingin mereka dapat diakses melalui jaringan berbagi. meletakkan segala sesuatu di bawah /middleearth(atau /srv) memungkinkan saya untuk membuat saham Samba tanpa membiarkan Samba berada di dekat direktori home pengguna saya. ini berguna untuk use case saya. dalam sistem multi-pengguna, Anda memusatkan data untuk alasan yang sama - sehingga Anda dapat memberi pengguna 1, 2, & 3 akses ke data tanpa membiarkannya masuk ke direktori home masing-masing.
quack quixote

3

Saya menggunakan /av- ini bagus dan pendek sehingga mudah untuk mengetik.

Kepatuhan FHS tidak menjadi masalah. FHS adalah standar untuk diikuti oleh distribusi dan aplikasi Anda. Distribusi atau aplikasi tidak boleh membuat direktori tingkat atas, tetapi sebagai pengguna dan administrator sistem, namespace sistem file adalah milik Anda untuk digunakan sesuai keinginan.

Memasukkannya ke dalam /homeadalah ide yang buruk, karena direktori itu adalah untuk direktori home. Direktori media bersama Anda bukan direktori home. Pertimbangkan bahwa jika Anda menggunakan /home/mediadan nanti perlu membuat pengguna yang disebut 'media'.

Demikian pula, hindari direktori yang dikelola oleh distribusi Anda. /usr/share/mediaadalah ide yang buruk, karena paket dalam distribusi Anda mungkin menggunakan jalur itu.

/usr/local, /optdan /srvdidefinisikan sebagai tempat di mana Anda memiliki kendali atas namespace di bawahnya, tetapi /optbiasanya untuk direktori aplikasi dan /srvuntuk data yang ditampung oleh host. /usr/local/sharemungkin cocok, tapi itu jalan yang terlalu panjang untuk seleraku.

Yang terpenting, ingat itu adalah sistem file Anda sehingga tidak ada yang salah dengan membuat direktori tingkat atas yang baru.


amin brothah man. seperti yang saya sebutkan sebelumnya, saya menggunakan /middleearth, karena mudah diingat, tetapi saya lakukan symlink /meuntuk pintasan berguna.
quack quixote,

2

<mode = pedant>
Menurut Standar Hierarki Filesystem , /usradalah untuk "data yang dapat dibagikan, hanya-baca"; /usr/shareadalah untuk "file data independen arsitektur read-only. ... misalnya, situs dengan platform i386, Alpha, dan PPC mungkin mempertahankan direktori tunggal / usr / share yang dipasang di pusat"

Jadi ya, subdirektori /usr/sharesepertinya pilihan yang tepat.
</mode>

<mode = pragmatis>

Kurang pedantically, / home (seperti yang disarankan oleh raphink) sepertinya pilihan yang baik. Anda mungkin memiliki / home di partisi sendiri, keduanya sehingga Anda dapat dengan mudah meniup sisa OS tanpa menyentuh data pengguna (misalnya, ketika melakukan upgrade atau instal ulang) dan untuk kemudahan cadangan (karena semua yang Anda ingin buat cadangannya) disimpan di / home), dan untuk alasan manajemen ruang (pada sebagian besar kotak home, partisi dengan / home akhirnya menjadi partisi yang kehabisan ruang terlebih dahulu).

</mode>


Saya tidak akan menganggap foto dan mp3 sebagai file hanya-baca. Saya cenderung mengedit foto saya cukup sering ;-)
--aphink

Dan video mungkin memiliki kebiasaan menghilang setelah mereka ditonton satu atau dua kali ... dan sebagian besar program perpustakaan media (saya sedang memikirkan iTunes, tetapi f-spot melakukan sesuatu yang serupa, dan saya yakin rhthymbox dan songbird juga melakukannya. ) akan memiliki beberapa jenis database dengan informasi jumlah permainan dan sebagainya - dan itu jelas bukan milik / usr. / home sepertinya pilihan yang masuk akal, bahkan jika itu tidak sepenuhnya sesuai FHS.
James Polley
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.