• Ismertető
  • Hírek
  • Letöltés
  • Súgó
  • Közösség
ubuntu.hu

Belépés

  • Felhasználó létrehozása
  • Elfelejtett jelszó

Facebook

Kapcsolat

  • Facebook oldal
  • IRC
  • Közösségi levlista
  • Segítői levlista
  • További elérhetőségek

[Megoldva] mount cifs többfelhasználós környezetben

2019. április 7. – 11.53 – .Bendegúz.
  • Hálózat, internet

Sziasztok!

Tudna valaki tanácsot adni abban, hogy többfelhasználós környezetben hogyan kell beállítani a cifs mountot, hogy egy hostról több felhasználó is használni tudja a megosztást (kijelentkezés-bejelentkezés után).

Tehát:
Adott egy Zentyal tartomány, amiben létre lett hozva egy megosztás (adatok) és két csoport (iroda,konyvtar) kapott hozzáférési (írás,olvasás) jogosultságot. A csoportokban egyelőre egy-egy felhasználó: iroda01, konyvtar01 van.
Ezt egy Linux Mint kliensről kellene felcsatolnom mount cifs megoldással, úgy, hogy mind a két tartományi felhasználó elérje, írni-olvasni tudja kijelentkezés-bejelentkezés után.

Ha ezt adom meg, akkor az iroda01 felhasználóval megy rendesen (írás-olvasás és a kuka is működik), viszont ha a másikkal jelentkezek be (konyvtar01) akkor persze az a felhasználó nem tudja használni a megosztást.

mount -t //192.168.10.1/adatok cifs -o username=domainadmin,password=alap,uid=iroda01,gid=iroda

Ezt később betenném az fstab-ba, csak sajnos ez elég egyfelhasználós módszer... :-(
Tehát ezt a mount megoldást kellene kiterjesztenem úgy, hogy a később létrehozott felhasználók is tudják majd használni a megosztást a host-ok felől. Létezik erre valami egyetemes megoldás?

‹ Wifi router beállítás [Megoldva] mount cifs többfelhasználós környezetben ›
  • A hozzászóláshoz regisztráció és belépés szükséges
klt – 2019. április 7. 15.03

Hasonlóra a gio mountot használom.
Bejelentkezéskor lefuttatok egy ilyesmi sscriptet:
sleep 3
gio mount 'smb://ubuserver/homes/'
.
.
.
gio mount 'smb://pch-a200/share/'

Előtte a egyszer a fájlkezelővel betallózom a kérdéses megosztásokat, a jelszót meg megjegyeztetem, és könyvjelzőt is adok hozzá.
Bejelentkezéskor script lefut, /run/user/userid/gvfs alatt vannak a csatolt hálózati megosztások.
Ezt linkelem a home könyvtárba.
Ha régebbi a rendszered, akkor gvfsmount lesz gio helyett.
Ne biztos, hogy a legszebb megoldás, de működik.

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 7. 16.53 – előzmény

Uhh, ez elég körülményesnek tűnik...

A rendszer Ubuntu 16.04 (zentyal5.1) és LinuxMin19.1 kliensek... ...tehát annyira nem régiek.
Jelenleg azt próbáltam ki, hogy a létező két felhasználóhoz felvettem az fstab-ba mindkét felhasználóhoz a megosztást:

//192.168.10.1/adatok /media/adatbank01 cifs -o username=domainadmin,password=alap,uid=iroda01,gid=iroda
//192.168.10.1/adatok /media/adatbank02 cifs -o username=domainadmin,password=alap,uid=konyvtar01,gid=konyvtar

Ez úgy ahogy működik, de nem túl elegáns. Ezt kellene egybegyúrni valahogy és erre nem találtam még semmi használhatót.
Valami ilyesmi jó lenne:

//192.168.10.1/adatok /media/adatbank cifs -o username=domainadmin,password=alap,uid=iroda01,konyvtar01,gid=iroda,konyvtar

Ez persze nem működik, de ilyesmi kellene.

Az iroda01 és konyvtar01 felhasználók domain userek, és a hoston be tudnak jelentkezni és home mappájuk is van, de az uid-jük és a gid-jük nem "hagyományos" -- 52200513 és 52201104

Ja és azért cifs megosztás, mert a digikam csak azt kezeli, és az miatt kell ez az egész hóbelebanc.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

klt – 2019. április 7. 16.56 – előzmény

Ha 100 gépen 1000 felhasználónál kell megcsinálni, akkor tényleg macerás. Itthoni hálózatban 5 gépen, 5 felhasználónak elmegy :)
Meg aztán, a gvfs (gio) módszerrel mindenkinek külön, saját megosztásrendszere csatolódik, amik eltérnek. Ha mindenkinek ugyanazt a szerkezetet akarnám felcsatolni, akkor lehet, hogy fstab-os megoldást választanám én is.

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 7. 17.07 – előzmény

Próbáltam azt is, hogy az adott megosztásra létrehoztam a szerveren egy saját csoportot és a mount-ba csak a gid-et adtam meg,

mount -t //192.168.10.1/adatok /media/adatbank01 cifs -o username=domainadmin,password=alap,gid=adatcsoport,dir_mode=0770,file_mode=0660

Felcsatolni felcsatolja és írni-olvasni is lehet a mappákat, csak épp a trash nem működik.
"A fájl nem helyezhető át a kukába. Akarja most rögtön törölni?"

  • A hozzászóláshoz regisztráció és belépés szükséges

 

sömike – 2019. április 7. 17.05 – előzmény

Szia!
Nem tudom vajon működhet?
Mindenkit beleteszel egy közös csoportba is. (nem tudom csoportokat lehet e csoportba tenni?)
Aztán csak a gid -et adod meg, eme új csoport névvel?

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 7. 17.09 – előzmény

Közben válaszoltam és ez is benne van.
Nem kell csoportot csoportba tenni, de a Trash-t elfelejthetem (vagy legalábbis még nem tudom hogyan lehet visszakapcsolni).

  • A hozzászóláshoz regisztráció és belépés szükséges

 

sömike – 2019. április 7. 17.16 – előzmény

Állítsd át a .local/share/Trash jogosultságait.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 7. 17.29 – előzmény

Mire?

Szerk.:
Enne a mappának a csoportbeállítása eleve a Domain Users volt, csak a Mappa elérése volt Nincs-re állítva.
Ezt beállítottam Fájlok létrehozása és törlése módra, így jelenleg: drwxrwx--- konyvtar01 Domain Users ... Trash

De így sem csinál Trash könyvtárat a megosztásra.
Törléskor a hibaüzenet: "Unable to find or create trash directory for /media/adatbank01/Névtelen mappa"

  • A hozzászóláshoz regisztráció és belépés szükséges

 

sömike – 2019. április 7. 17.47 – előzmény

Akkor talán ha a file_mod magasabb lenne. pld 777
szerk:
(Aztán majd visszább veszed ha műxik)

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 7. 18.27 – előzmény

Sajnos sem a dir_mode sem a file_mode 0777-re emelése nem ad Trash mappát a megosztott mappán.

Nagyon gyanús, hogy mivel csatoláskor lehagyom az uid-et a mount-ban, ezért nincs jogosultságom az éppen bejelentkezett felhasználó nevében Trash mappát létrehozni a megosztáson. Már csak azért is gondolom ezt, mert a létrehozott mappákat ezekkel a beállításokkal hozza létre:
Tulajdonos: root
Mappa elérése: Fájlok létrehozása és törlése

Csoport: Domain User
Mappa elérése: Fájlok létrehozása és törlése

Viszont a Trash-t (ha létrehozná) a root nevében kellene megtennie, közben meg a könyvtár01 felhasználóval indítom a törlést, aki csak "sima" Domain User. Talán ezért kellene a cifs csatolásba az uid is (uid-del van Trash), viszont akkor meg a mappa csatolását több felhasználónak nem tudom értelmesen megcsinálni.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

sömike – 2019. április 7. 17.50 – előzmény

Mondjuk az is érdekes, hogy miért "Névtelen mappa" néven akarja létrehozni???
Vagy csináld meg Te!!
Talán.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 7. 18.03 – előzmény

Teszt közben a Névtelen mappa-t töröltem és erre volt a válasza, hogy nem tudja törölni, mert nincs amibe beletörölje.

Csak megjegyezném, hogy biztos jó lenne az, ha a .local/share/Tarsh-ba törölne?
Az egy komplett másolási folyamat a hálózati megosztásról nem? Nagy fájloknál ez brutál sokáig tartana.
Nem az lenne a jó megoldás, ha a megosztáson jönne létre a Trash, oszt ebbe mozgatná át a törölt cuccokat?
Csak kérdem.

Ez viszont még nem működik ezzel a gid-es megoldással.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

sömike – 2019. április 7. 18.48 – előzmény

Bocs.
A Trash elérési útját a megosztott mappát tartalmazó fájlendszeren képzeltem el, nem az adott User mappájába.
DE!
A kérdés az, hogy egy törlésnél hol keresi a "Kuka" -t ??
Én úgy tapasztaltam, hogy ha például egy pendrive-ról törlünk egy fájlt, akkor a pendrive-on jön létre egy Trash mappa.
szerk:
Szóval egyéb meghajtón történő fájl törléskor a szemetet egy ilyen mapppába akarja helyezni:
.Trash-$UID
Tehát minden felhasználónak külön kukája lesz
De ennek a mappának a helye valsz a /media kell legyen. Vagy az adott rendszer (ahol a megosztások vannak) /home mappája.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 7. 18.50 – előzmény

" A Trash elérési útját a megosztott mappát tartalmazó fájlendszeren képzeltem el, nem az adott User mappájába."

Hát én is oda képzelem, de szerintem jogosultsági "hiányosságok" miatt nem tudja létrehozni. Miért gondolom ezt?
A mount-nál meg lehet adni, hogy melyik felhasználó-csoport nevében csatolódjon a hálózati mappa (uid,guid)
Ha csak a guid-et adom meg, akkor a csatolás tulajdonos a helyi gép root-ja lesz a csoportja meg amit a guid-ben megadtam (viszont konyvtar01 domain userrel vagyok bejelentkezve!)
A csoportnak meg valamiért nincs joga Trash mappát létrehozni a megosztáson.

Ha uid-et is megadok, akkor Trash-ba kerülnek a törölt elemek. Viszont így csak egy gép/egy felhasználó akihez csatolni tudok az fstab-ban.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

sömike – 2019. április 7. 18.50 – előzmény

De ha létrehozol mindenkinek egy mappát, és jogosultságot adsz neki, akkor az működhet.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 7. 19.46 – előzmény

Nem működhet sajnos, mert a .Trash-xxxxxxxx mappa a megosztáson belül jön létre.
Ha tehát a szerver felől felcsatolom az adatok mappát a host /media könyvtárába (/media/adatok), akkor a Trash az adatok mappában fog létrejönni.
Viszont, ha fstab-ban uid-nél egy a hoston létező felhasználót adok meg (rendszergazda), akkor az egész megosztáson belül a tulajdonos a rendszergazda felhasználó lesz, és ez nem is változtatható meg egyik almappán sem.

drwxrwx--- rendszergazda domain user .Trash-xxxxxxxx

Hiába hozom létre manuálisan a konyvtar01-hez tartozó .Trash-xxxxxxxx mappát a konyvtar01 felhasználónak, saját tulajdonba már nem tudom venni, így nem tudom megadni neki a szükséges jogokat, ezért a törölt elemek sem kerülnek ebbe a mappába.

Ha csatoláskor az uid=konyvtar01, akkor övé a Trash mappa is, viszont akkor a csatolást már másik felhasználó nem tudja használni.
És itt a kör bezárulni látszik.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

a mester – 2019. április 7. 20.05 – előzmény

"Hiába hozom létre manuálisan a konyvtar01-hez tartozó .Trash-xxxxxxxx mappát a konyvtar01 felhasználónak, saját tulajdonba már nem tudom venni, így nem tudom megadni neki a szükséges jogokat, ezért a törölt elemek sem kerülnek ebbe a mappába."
Miért kéne saját tulajdonba venni?
Rootként olyan jogokat csinálsz neki, amilyent nem szégyellsz.

  • A hozzászóláshoz regisztráció és belépés szükséges

gyakorlat teszi

.Bendegúz. – 2019. április 7. 20.19 – előzmény

De az a poén, hogy csatolás után már nem tudok jogokat kiosztani a megosztáson belül.
sudo chown konyvtar01: /.Trash-xxxxxxxx (x helyén a konyvtar01 uid-je)
Lefut, de nem változtat semmin.
A jogosultság beállítását a csatoláskor lehet változtatni, de ebből adódott az alapkérdés ami miatt itt vagyok.

Azért kellene saját tulajdonba venni, mert a csoportjogosultság nem elég neki a Trash mappa létrehozásához (hiszen a Trash mappa nevében is a felhasználó uid-je kerül az x-ek helyére: .Trash-xxxxxxxx).

Nem állítom, hogy nem nézek be valamit, de még sajna nem jöttem rá, hogy mit...

  • A hozzászóláshoz regisztráció és belépés szükséges

 

a mester – 2019. április 7. 20.36 – előzmény

De miért nem lehet csatolás _előtt_ létrehozni azt a kukát?

  • A hozzászóláshoz regisztráció és belépés szükséges

gyakorlat teszi

sömike – 2019. április 7. 20.43 – előzmény

Lehet nem értem/értjük a topológiát.
Van egy gép valamilyen oprendszerrel, amire telepítettél Zentyal-t, az ActiveDirectory miatt?

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 8. 9.11 – előzmény

A tényállás a követező:

Adott egy szerver Zentyal oprendszerrel, amin egy megosztott adatok mappa van megadva két felhasználónak iroda01-nek és könyvtar01-nek, iroda01 az iroda csoportnak, konyvtar01 a konyvtar csoportnak a tagja. Ezek a felhasználók domain felhasználók.
Az adatok megosztás hozzáférési jogosultságainál a hozzáférés engedélyezve van az iroda és a konyvtar csoportoknak.

Adott egy (több) munkaállomás, amin a két domain felhasználó be tud lépni és bejelentkezés után mindkettejüknek el kellene érni az adatok megosztást, tudniuk kellene írni-olvasni azt.
Ha fstab-ból csatolom a megosztást, akkor vagy a munkaállomás felhasználók érik el (csak a root-rendszergazda van) vagy csak a domain userek, de azok közül is csak az egyik, akinek a nevében felcsatolom (uid, guid).
Ha az fstab-ban csak a guid van megadva (domain user guid-ja), akkor mindkét domain user eléri a megosztást, írni-olvasni is tudja, de a Trash mappa nem jön létre, amit kitöröl a felhasználó, az végleg törlődik.
Erre írtam azt, hogy az fstab-os csatolás az erősen egyfelhasználós megoldásnak tűnik.
Röviden ennyi.

Arra gondoltam még, hogy domain user bejelentkezése után kellene valahogy létrehozni a csatolást és kijelentkezéskor lecsatolni a mappát.
Valami ahhoz hasonlóan mint amit klt fórumtárs javasolt.
Sok mindent nem találtam még ehhez, de rajta vagyok.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

sömike – 2019. április 8. 13.26 – előzmény

Oké.
Szerintem szükségtelen az fstab-ba írni bármit is, legalább is neked. Majd a rendszer elintézi, ha akarja.
Opció 1: Minden usernek hálózati meghajtóként csatolod, azt a mappát amihez hozzá kell férjen
Opció 2: Sima hálózaton tallózással érik el az adott mappát. Persze erre egy linket is ki lehet tenni, minden felhasználónak.
Én úgy tudom, hogy az fstab-ba írt csatolási jelzők (guid, stb ...), akkor kellenek ha:
A szerver nem közöl ilyen jellegű információkat a host-al. Ha közöl akkor pedig felülírod ezeket, azzal amit beleírsz az fstab-ba.
Tehát a szerveren beállított jogosultságok érvényesek lesznek akkor is, ha nem fsatb-ozol.
"Arra gondoltam még, hogy domain user bejelentkezése után kellene valahogy létrehozni a csatolást és kijelentkezéskor lecsatolni a mappát."
Szerintem ha a "hálózati meghajtó" felől közelíted meg a problémát, akkor ezt a rendszer megcsinálja magától.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 9. 4.23 – előzmény

Közben találtam valamit: https://askubuntu.com/questions/416535/mount-samba-share-at-login-using-...

"Szerintem szükségtelen az fstab-ba írni bármit is, legalább is neked. Majd a rendszer elintézi, ha akarja."
Elintézi, csak nem cifs csatolást csinál. A digikam meg csak azt hajlandó megenni. :-(
Arra amire te gondolsz egy sima parancsikon is megtenné az asztalon, vagy az smb:\\szerverneve\adatok parancs.

"Én úgy tudom, hogy az fstab-ba írt csatolási jelzők (guid, stb ...), akkor kellenek ha:"
Ez a fenti esetben igaz. Cifs-nél azért kell, hogy megmodd a rendszernek, hogy kinek a nevében csatolódjon fel a mappa.
Nélküle root:root lenne, kizárva így mindenkit a hozzáférés lehetőségétől.

Remélem nem értettelek félre.

" Szerintem ha a "hálózati meghajtó" felől közelíted meg a problémát, akkor ezt a rendszer megcsinálja magától."
A cifs megosztást "sajnos" nem csatolja le, legfeljebb más felhasználók csak böngészni tudják, írni-olvasni nem.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

sömike – 2019. április 9. 5.32 – előzmény

Igazad van! Bocs. Teljesen lehagytam ezt a cif-es dolgot.
Nem is értem magam ...

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 9. 8.17 – előzmény

"Nem is értem magam ..."
Nem gond, én már annak is örülök, hogy egyáltalán meg tudom ezeket beszélni valakivel.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

klt – 2019. április 9. 5.39 – előzmény

Igazából nem ismerem a Digikamot, de nekem az valami hihetetlen fura, hogy egy mezei könyvtárba nem tud dolgozni a gépen?
Ha meg igen, akkor nem mindegy neki, hogy az hogyan van ott? Fájlrendszerben máshonnan linkelve, vagy csatolva cifs, esetleg NFS?

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 9. 7.56 – előzmény

Mezei könyvtárba tud dolgozni, csak a távoli könyvtárak csatolása nem mindegy neki. Cifs és azt hiszem az nfs is működik, viszont egyebet be sem lehet benne tallózni (egyébként ezt jelzi is programon belül).
Nagyon ügyes progi különben, mysql adatbázissal megtámogatva még a 300 ezer képet tartalmazó gyűjteménnyel is elboldogul (persze néha percekig szüttyög, de ez inkább csak a 100 ezer vagy annál több képet tartalmazó Albumoknál jellemző. Ha minden bélyegképet feldolgozott, utána pörög piszkosul.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

klt – 2019. április 9. 6.07 – előzmény

Ezt nézd meg!
https://unix.stackexchange.com/questions/112063/how-can-i-have-a-trash-r...

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 9. 8.20 – előzmény

Na ezzel meg az a vicces, hogy a Zentyal-ban ez alapból bekapcsolható.
De ennek is az a feltétele, hogy a felhasználó legyen a megosztás tulajdonosa.
Ha bekapcsolom és mount-nál megadom az uid-et is (a felhasználóé lesz a mappa), akkor cifs megosztás esetén létrehozza ezt a recycle köyvtárat ÉS bónuszként a kliens gép is létrehozza a maga kis Trash könyvtárát ugyanoda. Magyarán két Lomtár is létrejön. Vicces. Nem cifs megosztással persze működik.
Ezért kikapcsoltam ezt a funkciót, és ha megoldom a bejelentkezés utáni csatolást - kijelentkezés utáni lecsatolást, akkor Trash mappám is lesz és nem kell a samba-s recycle megoldás.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

klt – 2019. április 9. 9.22 – előzmény

Akkor vissza az első ötlethez:
//192.168.10.1/adatok /media/adatbank cifs -o username=domainadmin,password=alap,uid=iroda01,konyvtar01,gid=iroda,konyvtar

A felhasználóid iroda01, konyvtar01?

Mi van, ha csinálsz egy új csoportot, pl.: akikirhatnakide
Aztán
usermod -a -G akikirhatnakide iroda01
usermod -a -G akikirhatnakide konyvtar01

A csatolást maeg valami ilyesmi módon intézed:

mount -t //192.168.10.1/adatok /media/bank cifs -o username=domainadmin,password=alap,uid=nobody,gid=akikirhatnakide
Bocs, ha már próbáltad.

Vagy esetleg, valami ilyen:
mount -t //192.168.10.1/adatok /media/bank cifs -o username=domainadmin,password=alap,file_mode=0777,dir_mode=0777,noperm

Szerk.: most látom, hogy valami ilyesmit próbáltál, csak a SZERVEREN hoztál létre csoportot. Én a kliens gépen gondoltam ezt, és ahogy nézem, sömike is ezt javasolta. Persze, ha félre nem értettem valamit...

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 9. 16.41 – előzmény

Ezek a változatok ott buknak meg, hogy csoport tapasztalatom szerint nem tud Trasht létrehozni. Ha tehát nem adom meg direktben az uid-nél a domain user nevét, akkor teljesen esélytelen a Trash létrejötte, bármit bűvészkedem a csoportokkal és egyéb kapcsolókkal.

Most azt fogom még kipróbálni, hogy bejelentkezéskor és kijelentkezéskor miként lehet csatolást létrehozni...

Ahogy olvasgattam, szerencsésebb lenne nfs megosztásokat használni (linux kiszolgáló - linux kliensek), csak sajnos benne van a pakliban, hogy a felhasználók letérdelnek a linux használatától és windows-ra kell visszatenni mindent (ez nagy szop@s lenne, de benne van a pakliban). Ezért a samba-s cifs-es próbálkozás, hogy legalább szerver oldalon ne kelljen sokat variálni ha váltani kell.

Lényeg, hogy patentül elő kell készítenem mindent, hogy leessen az álluk és élmény legyen használni, ne pedig csalódás.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

klt – 2019. április 9. 16.47 – előzmény

Nem is a csoport hozza létre, hanem a felhasználó, akinek joga van, mert tagja egy csoportnak... asszem...
Azér' próbáld még ki azt a noperm opciót is, hátha...

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

klt – 2019. április 9. 17.04 – előzmény

Itt:
"...username=domainadmin,password=alap,gid=adatcsoport,dir_mode=0770,file_mode=0660"
kik voltak az adatcsoport tagjai?

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 9. 18.28 – előzmény

kik voltak az adatcsoport tagjai?
Ha az adatcsoportba berakom az iroda01 és konyvtar01 felhasználót az sem oldja meg, mert akkor is az uid nevében hozza létre a Trash-t.
noperm kipróbálva --> nincs Trash

Tehát: ... gid=adatcsoport,noperm,dir_mode=0770,file_mode=0660 ...
Eredmény: Nem csinál Trasht, csak azonnali törlést enged. Persze a csoportjogok miatt lehet írni-olvasni a mappákat-fájlokat. Ja és a helyi gép root-ja a tulaj...

Viszont...
Ezen leírás alapján (https://askubuntu.com/questions/416535/mount-samba-share-at-login-using-...) működik rendesen minden! Bejelentkezés után felcsatolja és Trash is van.
Már csak a lecsatolást kell megoldani kijelentkezéskor és minden istenkirályságos lesz!

Ha sikerül biztos írok majd egy rövid összefoglalót, hátha még később másnak szüksége lesz rá.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

klt – 2019. április 9. 21.41 – előzmény

A lényeg, hogy megy ;)
Lesd meg, hátha jó valamire:
http://superuser.com/questions/65460/ddg#65526

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 10. 7.15 – előzmény

Na, működik végre!
Igaz három nap kellett hozzá, de megy rendesen!

Még letesztelem és megírom okulásként az utókornak.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 10. 10.12

Srácok!
Köszönöm mindenkinek, hogy foglalkoztatok a problémával!

Akkor ahogy ígértem a leírás:

Az alapprobléma (ha valaki nem akarja végigolvasni az összes hozzászólást):
Adott egy Zentyal szerver és néhány domain user (iroda01, konyvtar01 stb., csoportjaik: iroda, konyvtar stb.)
A szerveren létrehozott megosztások jogusultságait kliensen -- cifs mount esetén -- a samba nem veszi át, így azokat csatoláskor be kell állítani a kliensen bejelentkezett domain usereknek.
Ennek hiányában vagy hozzáférési gondok lesznek, vagy Trash meghajtó nem jön létre a felcsatolt hálózati meghajtón. Törölni persze lehet, csak nem a kukába.
Többfelhasználós környezetben -- egy munkaállomás, több felhasználóval -- az fstab szerkesztése nem ad megfelelő eredményt, mert minden felhasználóhoz fel kell venni egy csatolási beállítást -- akár ugyanahhoz a megosztáshoz is --, így minden felhasználónál megjelennek azok a csatolt megosztások is, amihez tulajdonképpen hozzáférési joga sincs. Működik, de felesleges és nem használható megosztásokkal szemeteli tele az elérhető megosztások "listáját".

Először is a források:
https://askubuntu.com/questions/416535/mount-samba-share-at-login-using-...
https://askubuntu.com/questions/155791/how-do-i-sudo-a-command-in-a-scri...
https://forums.linuxmint.com/viewtopic.php?t=270140

A megoldás
A megoldás számomra az lett, hogy minden felhasználónak bejelentkezéskor csatolom a számára használható megosztást, kijelentkezéskor pedig ez a megosztás lecsatolódik. Így más felhasználó számára nem marad "szemetes" a megosztások listája, mindenki csak azt látja amit joga is van használni.

Lépésről-lépésre
MOUNT
Legyen a bejelentkeztetni kívánt felhasználó az iroda01

-- iroda01 home mappájában létrehoztam egy "szkriptet", ez fogja majd intézni a csatolást.
Legyen a neve mondjuk .cifsmount

-- Tartalma nagyon egyszerű, csak maga a muont parancs és a csatolás paraméterei (és semmi egyéb!):

mount -t cifs //(szerverneve.domainneve.lan)/(megosztásneve) /media/(mappa, amibe csatolom)/ -o username=(domain admin neve),password=(domain admin jelszav),uid=(domain user neve),gid=(domain user csoportja),dir_mode=0770,file_mode=0660

Nálam ez így néz ki:
mount -t cifs //vehiszerver.iskola.lan/adatok /media/adatbank/ -o users=vehidomainadmin,password=alap,uid=iroda01,gid=iroda,dir_mode=0770,file_mode=0660

-- Ha kész, állítsd be a fájl tulajdonosát és jogosultságait (csak root írhatja-olvashatja-és ami a legfontosabb futtathatja is)
sudo chown root:root .cifsmount
sudo chmod u+rwx,g-rwx,o-rwx .cifsmount

-- Most be kell állítani, hogy ez a fájl -- és a benne lévő mount -- lefuthasson a root nevében bejelentkezéskor. Ehhez szerkeszteni kell az /etc/sudoers fájlt.
Nyisd meg és kb. a huszonötödik sor körül lesz egy bejegyzés:
# All members of group sudo to execute any command
Itt add hozzá a fent létrehozott .cifsmount fájlt a következő módon:
iroda01 ALL(ALL) NOPASSWD: /home/(user mappájának elérési útja)/.cifsmount
Mentés, bezárás.

-- Egy dolog van még: Bejelentkezéskor valahogy le kell futtatni a .cifsmount-ot
Linux Mint-en -- és gondolom a többi distroban is -- van erre lehetőség. Mint-en nyisd meg az Indítópult alkalmazást és adj hozzá egy sort a listához:
- Egyéni parancs hozzáadása
Név: Megosztott mappa csatolása
Parancs: sudo /home/(user mappájának elérési útja)/.cifsmount
- Hozzáadás
Itt van lehetőség kipróbálni is, hogy működik-e: kattints a Futtatás most ikonra (alul, jobbról az első)
Ha rendben felcsatolta a meghajtót, akkor lehet örülni.

UMOUNT
LinuxMint lightdm-et használ a bejelentkezések kezelésére, ezért az umount-hoz azt kell egy picit módosítani.

-- root home mappájában hozz létre egy szkriptet, ez fogja intézni a lecsatolást.
Legyen a neve mondjuk .cifsumount

-- Tartalma nagyon egyszerű:
#!/bin/bash
umount /media/(a felcsatolt megosztás neve)
exit 0

-- Ha kész, állítsd be -- vagy legalább ellenőrizd, hogy biztosan ezek legyenek -- a fájl tulajdonosát és jogosultságait (csak root írhatja-olvashatja-és ami a legfontosabb futtathatja is)
sudo chown root:root .cifsumount
sudo chmod u+rwx,g-rwx,o-rwx .cifsumount

-- Nyisd meg az /etc/lightdm/lightdm.conf fájlt
Adj hozzá egy sort a [Seat:*] alatt valahol:
session-cleanup-script=/root/.cifsumount

-- Mentés és újraindítás. Belépés után a hálózati megosztott mappának fel kell csatolódnia, jogosultságai a bejelentkezett felhasználóé, törléskor létre kell jönnie a .Trash-xxxxxxxx mappának (x helyén a felhasználó id-je van, ami lekérdezhető a terminálban kiadott id paranccsal) és kijelentkezéskor le kell csatolódnia.

Megjegyzés
Több felhasználó és egyéb csatolni kívánt megosztás esetén értelemszerűen bővíteni kell a .cifsmount, .cifsumount és /etc/sudoers fájlokat!

Ennyi.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

klt – 2019. április 10. 10.13 – előzmény

Nem kapnak ezzel a gyalogjúzerek sudo-zási lehetőseget?
Mondjuk pl. iroda01 tud-e
sudo rm / -rf
parancsot adni?

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 10. 10.41 – előzmény

Nem. Csak az az egy fájl tud lefutni, amit beállítottam (.cifsmount), hogy indíthassa root jogokkal. A felhasználó nem fér hozzá a fájl tartalmához sem, mert az meg a root-é, így nem képes "gonosz kis okosságokat" beletenni.

Ha a NOPASSWD: után ALL lenne, akkor biztos izgalmasabbá tennék az életem. :-)

  • A hozzászóláshoz regisztráció és belépés szükséges

 

klt – 2019. április 10. 11.11 – előzmény

Köszi! Megint tanultam valamit! :)

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 10. 16.12 – előzmény

Egy apró változtatással univerzálisabbá lehet tenni a mountolást.
Abból kiindulva, hogy az umountot a lightdm intézi, csinálja az a mountot is.

A MOUNT szakaszban, onnan, hogy "-- Egy dolog van még: Bejelentkezéskor valahogy le kell futtatni a .cifsmount-ot"

Ez helyett:
-- Hozd létre a /usr/local/bin/allusercifsmount fájlt és tedd futtathatóvá (fentebb leírva, hogy kell)
Tartalma:
#! /bin/sh
if [ -e $HOME/.cifsmount ]; then sudo "$HOME/.cifsmount"; fi

-- Az /etc/lightdm/lightdm.conf fájlhoz add hozzá a session-setup-script =/usr/local/bin/allusercifsmount bejegyzést.

-- Indítsd újra a lightdm-et: sudo service lightdm restart

Ettől kezdve annak a felhasználónak, akinek létezik a saját mappájában a .cifsmount fájl, annak az végre is hajtódik.

Megjegyzés:
Minden eddigi megoldáson eddig egy dolog fogott ki, a Felhasználóváltás. Na ezt nem tudja kezelni egyik megoldás sem. :-(

  • A hozzászóláshoz regisztráció és belépés szükséges

 

a mester – 2019. április 10. 16.14 – előzmény

https://linuxmint.hu/forum/cinnamon-felhasznalovaltas-kikapcsolasa
:Đ

  • A hozzászóláshoz regisztráció és belépés szükséges

gyakorlat teszi

.Bendegúz. – 2019. április 10. 16.26 – előzmény

Énvótam. :-)

  • A hozzászóláshoz regisztráció és belépés szükséges

 

csuhas32 – 2019. április 10. 19.48 – előzmény

https://github.com/linuxmint/Cinnamon/issues/6136

  • A hozzászóláshoz regisztráció és belépés szükséges

Ubuntu 20.04

klt – 2019. április 10. 19.59 – előzmény

Mi vóna, ha nem media/izébizé csatoltatnád a hálózati helyet, hanem minden felhasználónak a saját home könyvtárába valahova.
Elvileg minden user-nek külön példánya van a cifsmount-ból, nem hiszem, hogy gondot jelentene... A megérzésem azt súgja, hogy ez kompatibilis lenne a felhasználóváltással, és akkor nem kéne letiltani.
Vagy rosszul gondolom?

  • A hozzászóláshoz regisztráció és belépés szükséges

Adj egy falat falat, mondta a falat faló faló.

.Bendegúz. – 2019. április 11. 6.41 – előzmény

Hmmm.
Jó ötlet, köszönöm. Meg fogom tesztelni ezt is... ...lehet így le sem kell választanom kijelentkezéskor-felhasználóváltáskor (eddig csak azért kellett, hogy a másik felhasználó ugyanoda be tudja csatolni a megosztást).

  • A hozzászóláshoz regisztráció és belépés szükséges

 

.Bendegúz. – 2019. április 11. 14.35 – előzmény

Működik de mégsem jó így. A digikam minden felhasználónak újra akarja indexelni az adatbázist. :-(
Marad az első megoldás. Mindegy, jó úgy is.

  • A hozzászóláshoz regisztráció és belépés szükséges

 

Hozzászólás-megjelenítési lehetőségek

A választott hozzászólás-megjelenítési mód a „Beállítás” gombbal rögzíthető.
© 2007–2020. Magyar Ubuntu Közösség.
Az Ubuntu a Canonical bejegyzett védjegye.
Az ubuntu.hu az fsf.hu kiszolgálóin fut.