macOS vs. CurlFtpFS: read-only meghajtó...amit a Sublime tud írni

Fórumok

Egy haverom macOS-t használ (latest 12-est) és sehogy nem tudjuk neki összelőni, hogy az FTP könyvtára írható meghajtóként legyen felcsatlakoztatva a CurlFtpFS segítségével. (Tudom, hogy van open ftp://stb is, de az dokumentáltan és deklaráltan read-only mount by design, szóval nem opció itt.)

Aszondjuk terminálban, hogy

curlftpfs -o allow_other,ftp_port=- user:pass@host ~/mnt/ize

és ez fel is csatolja a cuccot, de a macOS azt írja rá, hogy read-only. Namármost, itt jön az érdekes rész: annak ellenére, hogy ez read-only (és tényleg az, sem terminálból, sem Finderből nem tudunk rá másolni, vagy bármit szerkeszteni, létrehozni, törölni rajta), ha kinyitunk Sublime-mal egy szöveges fájlt, akkor az feldob egy popupot és közli, hogy a júzere jelszavát (nem a rendszergazdáét) kéri. Ha megadjuk neki, akkor a Sublime gond nélkül írja rajta a fájlokat. De rajta kívül senki más. Megpróbáltuk úgy mountolni, hogy nem a júzerével, hanem su és rootként. Annyi volt a különbség, hogy terminálból, ha hétköznapi júzerek voltunk, akkor "permission denied" volt az eredmény minden írási kísérletre, ha meg root, akkor meg "operation not supported". A root userrel próbáltuk úgy is, hogy allow_root opcióval, úgy sem ment.

A fenti parancssor Linux alatt írhatóként csatolta fel az FTP könyvtárat és minden működött vele: feltöltés, szerkesztés, törlés, szóval a hiba - elméletileg - nem a paraméterekben van.

Nincs kizárva, hogy macOS alatt valamit máshogy kéne csinálni, de azt én sajnos nem tudom, hogy mit és a neten semmit nem találtam ezzel kapcsolatban...azon túl, hogy mások is szívnak vele.

Akinek van ötlete, megköszönöm.

Hozzászólások

Mindenképpen jogosultsági hibának tűnik. Próbáljátok meg az -o kapcsoló után az umask=111 vagy umask=110 paramétert, hogy akkor kér-e jelszót.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

MacOS-nél sose tudod, hogy az Apple mit kevert, mit korlátozott a háttérben. Nehogy felüljetek ám annak a szokásos bullshitnek, hogy a MacOS az még valódi Unix. Ma már az összes hasonszőrű OS már eleve csak unixlike, mert annyira komplexek, annyira sok millió kódsorosak, hogy a régi unixos kódból kb. semmi nincs már benne, néhány ősi API meg alapelv kivételével, meg van bennük POSIX kompatibilitás, de ezzel kifújt A helyzetet tovább rontja, hogy míg a Linux, BSD-k nyílt forráskódosak, és emiatt nyílt kártyákkal játszanak, addig a MacOS zárt, proprietary, ahol felhasználóként lekorlátoznak, elzárnak előled ezt-azt, hogy ne tudd más gépen lewarezolni, ne tudd a Store-jukat, zárt ökoszisztémájukat megkerülni, mert az nekik fő bevételforrás.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Egyes részei nyíltak tudtommal. Más részről a mai MacOS-ben elég kevés lehet már a kódjából annak is.

Annyit még, hogy nem biztosan az umask tér el, lehet valami másik jogosultsági beállítás nem engedi, de ettől még az umask állítása megoldás lehet. Nem garantálom, mert nem használok Mac-et, de hasonló jogosulsági problémánál nekem sok másik disztrón, BSD-n segített már.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nehogy felüljetek ám annak a szokásos bullshitnek, hogy a MacOS az még valódi Unix.

Nem mintha a téma szempontjából bármennyire is releváns lenne, de ez a gatekeeping kicsit félrement

https://www.opengroup.org/openbrand/register/

Vagy éppen a megkerülhetetlen Store, egy macOS gépre azt és onnan telepítesz, amit akarsz. Akár más alkalmazásboltot is. 

Te mennyit használtál eddig macOS-t?

Szerkesztve: 2022. 06. 05., v – 21:42

Nem a SIP fogja meg? Másrészt macos-en nem a /mnt használatos ilyesmire, hanem a /Volumes, próbáld ki ott, hátha. Esetleg:

sudo mount -uw /mnt/ize

Nem a SIP fogja meg?

Nem hiszem, akkor a Sublime sem tudná írni a jelszó bekérésével...vagy igen?

Másrészt macos-en nem a /mnt használatos ilyesmire, hanem a /Volumes, próbáld ki ott, hátha.

És az írható a mezei júzer számára is? Csak mert nem a /mnt alatt van a mountpoint, hanem a ~/mnt alatt.

Esetleg:
sudo mount -uw /mnt/ize

Mennyivel vagyunk előrébb, ha sudo-val csatoljuk, mint ha tényleg su-val átváltanánk root-ra és úgy? Egyébként sima mount-tal tudtommal nem lehet felcsatolni FTP könyvtárat. A mount_ftp és a open meg read-only módon csatol.

Nem a root lesz az ownere mount utan a foldernek, ahova mountoltad? Ha megadod a "-o uid=xxx" opciot, nem javul meg? Nekem igy mukodik.

Erről van szó? Pont nem a terminálban lenne rá szükség, hanem Finderben, meg az alkalmazásokban, hogy az FTP könyvtárat úgy tudja használni, mint ha helyi könyvtár lenne, a terminált nem is használja a srác. (Amúgy én azt hittem, hogy ha root vagyok, akkor ott full disk access van alapból...) Mondjuk ezt is meg lehet próbálni, hogy ha a Findernek megadjuk, akkor tud-e feltölteni vele, köszi a tippet.

Igen, oda alkalmazasokat tudsz felvenni.

En, ha siman mountolom, akkor az userem nem tud irni, de sudo mkdir mukodik (de ugye en nem vagyok teljesen relevans a SIP miatt). Ha hasznalom az uid opciot, akkor pedig mindennel tudok irni. A curlftpfs macportsbol jott, ez a verzioja: "curlftpfs 0.9.2 libcurl/7.83.1 fuse/2.9".

Most ott tartunk, hogy egyik javasolt megoldás se működött, viszont kiderült, hogy könyvtárakat tudunk létrehozni. A feltöltés viszont elszáll, debug mode-ban ez jön ki rá:

LOOKUP /public_html/css/add.svg
getattr /public_html/css/add.svg
   unique: 10, error: -2 (No such file or directory), outsize: 16
unique: 14, opcode: CREATE (35), nodeid: 33, insize: 64, pid: 79646
create flags: 0xa02 /public_html/css/add.svg 0100644 umask=0000
ftpfs: operation ftpfs_open failed because Operation not supported
   unique: 14, error: -45 (Operation not supported), outsize: 16
ftpfs: operation ftpfs_getattr failed because No such file or directory
   unique: 18, error: -2 (No such file or directory), outsize: 16

Szóval azért nem lehet feltölteni rá, mert a CurlFtpFS nem támogatja a CREATE-et. (Egyébként kipróbáltuk, a Sublime sem tud új fájlt menteni, csak régit felülírni.)
Lehetséges lenne ez?
Nekem Linux alatt:
curlftpfs 0.9.2 libcurl/7.38.0 fuse/2.9
Neki macOS alatt:
curlftpfs 0.9.2 libcurl/7.80.0 fuse/2.9
Ha itt megy, ott is mennie kéne...

Igaz. En is csak mkdir segitsegevel probaltam korabban, hogy lehet-e irni, az mukodott. Meglevo file modositasa is megy, de uj file letrehozasa nem, ugyhogy le is toroltem. Eddig se volt fenn, ezutan sincs ra szukseg.

 

Nincs barmi mas, ami ujabb? 2008 elegge regen volt, lehet volt valtozas a FUSE-n belul, vagy lehet, hogy van valami, ami a Maces FUSE alatt mashogyan mukodik emiatt a pluginnak is alkalmazkodnia kellene hozza.

Miert lenne ugyonaz? Emlekeim szerint azon tul, hogy hasonlo API-t valosit meg a Maces verzio, nincs sok kozuk egymashoz. Ahogyan itt is irjak, "It provides multiple APIs, one of which is a superset of the FUSE API (file system in user space) that originated on Linux. Therefore, many existing FUSE file systems become readily usable on macOS.".

Elkepzelheto, hogy van valami, amit itt mashogy kellene a fejlesztonek csinalnia, pl. mert a jelenlegi, 2008-as kodban hasznalt megoldas pl deprecated. Nem ismerem, nem hasznalom a MacFUSE-t, igy nem tudom megmondani, hogy mas Linuxos FUSE filerendszer is ugyonigy mukodik-e, vagy nem. 

Oké, így már érthető, hogy hol van a félreértés. Ez abszolút a fejlesztők hibája, mert ha másik API-t használ, akkor át kéne nevezni a programot, vagy curlftpfs-mac-re vagy macftpfs-re, vagy hasonlóra. Ez az egyik, amit nem szoktam szeretni Maceken, hogy csak azért is máshogy csinálnak mindent, mert ők a nagy Apple, meg ők nem átlag PC-s pórnépnek fejlesztenek, nekik abszolút egyedi és zárt megoldás kell, ami csak Macen működik.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem igazan ertem mirol beszelsz es mit akarsz atnevezni :D

Van a curlftpfs nevu szoftver, ami egy FUSE userspace filerendszer. Ebbol valamikor 2008-ban volt uj verzio utoljara. Van a macfuse/osxfuse, ami egy olyan szoftver, aminek semmi koze az Applehoz. Ez a macfuse/osxfuxe azt igeri, hogy megvalositja a Linuxos FUSE API supersetjet, amivel a Linuxos FUSE filerendszerek (mint pl a korabban emlegetett curlftpfs) mukodik. Elkepzelheto, hogy ez a megvalositas nem teljes, de akar az is, hogy valtozott az elmult 14-15 evben a FUSE API, a Maces fejleszto pedig nem implementalta az "osi", "elavult" API-t, csak az ujabb verziot. 

Nekem az egész hihetetlenül hangzik, mert Linuxon (Kubuntu, Arch) és is használtam curlftpfs-t, és nem csak az mkdir működött, de Double Commanderben a mappalétrehozás, mappa rámásolása is.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”