SFTP permission denied: შესვლა გამოდის, ფაილების შეცვლა კი - არა

თუ შენი SFTP კლიენტი შედის სერვერზე, გიჩვენებს საქაღალდეებს და უპრობლემოდ ჩამოტვირთავს ფაილებს, მაგრამ ყოველი შენახვა, ატვირთვა თუ წაშლა Permission denied-ით მთავრდება, პრობლემა ავტორიზაცია არ არის. ავტორიზაცია გაიარა. ჩავარდა შემდეგი შემოწმება: ოპერაციული სისტემა (ან პანელის SFTP სერვისი) წყვეტს, შეუძლია თუ არა იმ მომხმარებელს, რომლითაც შეხვედი, კონკრეტულ ფაილში ან მის შემცველ საქაღალდეში ჩაწერა. თუ სერვერს თავად მართავ, მიზეზი თითქმის ყოველთვის მფლობელია: ფაილები service user-ს ან root-ს ეკუთვნის, შენ კი სხვა მომხმარებლით შეხვედი. თამაშების პანელზე მიზეზი თითქმის ყოველთვის პანელის უფლებაა, დაცული ფაილი ან სავსე დისკი. გამოსავალი არასოდეს არის chmod 777.

ეს სტატია მიზეზებს იმ თანმიმდევრობით გადადის, როგორც რეალურად ხვდება პრაქტიკაში, და თითოეულისთვის გვიჩვენებს დამადასტურებელ ბრძანებას და გამოსწორებას, რომელიც ახალ პრობლემას არ შექმნის. ფაილის უფლებები და შესრულების ბიტი დეტალურად განხილულია სტატიაში თამაშის სერვერის ფაილების უფლებები და მფლობელობა, აქ კი ყურადღება გვაქვს კონკრეტულ სიტუაციაზე: დაკავშირებული ხარ, მაგრამ ჩაწერა მაინც არ გამოდის.

წაკითხვა გამოდის, ჩაწერა - არა: რატომ#

SFTP ცალკე უფლებათა სისტემა არ არის. ჩვეულებრივ Linux სერვერზე OpenSSH-ის sftp-server (ან internal-sftp) იმ მომხმარებლის სახელით მუშაობს, რომლითაც შეხვედი, და ყოველი ფაილური ოპერაცია ამ მომხმარებლის მიერ გაკეთებული ჩვეულებრივი სისტემური გამოძახებაა. თუ alice shell-იდან ფაილში ვერ წერს, SFTP-ითაც ვერ დაწერს. SFTP კლიენტი უბრალოდ იმას გადმოგცემს, რაც kernel-მა თქვა.

წასაკითხად ბევრად ნაკლები სჭირდება, ვიდრე ჩასაწერად. server.properties-ის ჩამოსატვირთად ფაილზე გჭირდება r, მის ზემოთ ყველა საქაღალდეზე კი x. შესაცვლელად ფაილზე გჭირდება w. ახალი ფაილის ასატვირთად, წასაშლელად ან სახელის გადასარქმევად საქაღალდეზე გჭირდება w და x, ფაილის საკუთარი უფლებებისგან დამოუკიდებლად. სწორედ ამ ასიმეტრიის გამო არის ასე გავრცელებული საჩივარი „ყველაფერს ვხედავ, მაგრამ ვერაფერს ვცვლი": ფაილების ნაგულისხმევი უფლებაა 644, საქაღალდეების - 755, ანუ მფლობელის გარდა ყველას აქვს ზუსტად ეს - წაკითხვა, სიის ნახვა, ჩამოტვირთვა და მეტი არაფერი.

პირველ რიგში დარწმუნდი, რომ შეცდომა ჩაწერის შეცდომაა და არა შესვლის. ეს ორი სხვადასხვა პრობლემაა:

Permission denied (publickey,password).          <- login failed, see SSH keysError: /srv/game/server.properties: open for write: permission deniedremote open("/srv/game/start.sh"): Permission deniedCouldn't open for writing

პირველი ხაზი ნიშნავს, რომ საერთოდ ვერ შეხვედი, და ამისთვის არსებობს SSH permission denied (publickey). ქვემოთ ყველაფერი დანარჩენ სამს ეხება, რომლებიც ერთსა და იმავეს ნიშნავს: შესული ხარ, მაგრამ ერთ ფაილზე ან ერთ საქაღალდეზე უარს გიგებენ. ზუსტი ტექსტი კლიენტზეა დამოკიდებული: FileZilla წერს open for write: permission denied, OpenSSH-ის sftp კლიენტი - remote open(...) ან dest open, რედაქტორის დამატებები კი ჩვეულებრივ ამბობენ, რომ ფაილი ჩასაწერად ვერ გახსნეს.

ვინ არის ფაილის მფლობელი და ვინ ხარ შენ#

თითქმის ყველა შემთხვევას ორი ბრძანება პასუხობს. SSH-ით ან sftp ხაზიდან გადახედე ფაილსა და მის საქაღალდეს:

$ ls -la /srv/game/drwxr-xr-x  5 steam steam 4096 Oct 14 20:10 .-rw-r--r--  1 steam steam 1843 Oct 14 20:11 server.properties-rw-r--r--  1 root  root   612 Oct 12 09:02 mods.json$ iduid=1001(alice) gid=1001(alice) groups=1001(alice)

წაიკითხე ეს როგორც წინადადება. საქაღალდე steam-ს ეკუთვნის და მასში მხოლოდ steam-ს შეუძლია ჩაწერა. server.properties steam-ს ეკუთვნის და მხოლოდ steam-ს შეუძლია მისი შეცვლა. mods.json root-ს ეკუთვნის, ამიტომ მისი შეცვლა steam-საც კი არ შეუძლია. შენ კი alice ხარ, არც ერთი და არც მეორე, ამიტომ შენზე მხოლოდ ბოლო სამი ბიტი მოქმედებს: საქაღალდეზე r-x, ფაილებზე r--. მხოლოდ წაკითხვა, ზუსტად ისე, როგორც დააფიქსირე.

გრაფიკული კლიენტები იგივე სვეტებს აჩვენებენ. FileZilla-ში remote პანელს აქვს Permissions და Owner/Group სვეტები, WinSCP-ში - remote პანელში და ფაილის Properties-ში. თუ მფლობელის სვეტში სახელის მაგივრად რიცხვია (988, 1000), ეს ნიშნავს, რომ კლიენტმა ამ id-ის სახელი უბრალოდ არ იცის - მფლობელობა მაინც რეალურია.

ქვემოთ მოცემულ ცხრილში ჩანს, რა გჭირდება თითოეული ოპერაციისთვის. ყურადღება მიაქციე, რამდენად ხშირად არის საქაღალდე ფაილზე მნიშვნელოვანი:

ბოლო ხაზზე ებჯინება ადამიანი რედაქტორების გამო, ამიტომ მას ქვემოთ ცალკე თავი აქვს.

სერვისის ან root-ის შექმნილი ფაილები#

VDS-ზე ან სახლის სერვერზე ამბავი ჩვეულებრივ ასეთია. თამაში, ვებაპლიკაცია ან ბოტი ცალკე service user-ით მუშაობს - steam, www-data, minecraft. კონფიგურაციის შესაცვლელად SFTP-ით საკუთარი მომხმარებლით შედიხარ. შენს მომხმარებელს ყველაფრის წაკითხვა შეუძლია (ფაილები 644-ია), ჩაწერა კი - არაფრის. ან ერთხელ გაასწორე და ისევ დაბრუნდა, რადგან სერვისი ახალ ფაილებს საკუთარი მფლობელითა და 022 umask-ით ქმნის. ან ვიღაცამ განახლება sudo-თი გაუშვა და ახლა რამდენიმე ფაილი root-ს ეკუთვნის და სერვისიც კი ვერ ცვლის.

სამი გონივრული გამოსავალია და რომელი სწორია, იმაზეა დამოკიდებული, ვინ უნდა ფლობდეს მონაცემებს.

შედი service user-ით. ყველაზე მარტივი ვარიანტი, როცა სერვერს ერთი ადამიანი ადმინისტრირებს. service user-ს მიანიჭე SSH გასაღები (არა პაროლი) და მისით დაუკავშირდი. ყველაფერს, რასაც ატვირთავ, თავიდანვე სწორი მფლობელი ექნება. თამაშის სერვერის user-ისთვის ეს ნორმალურია, www-data-სთვის ან სხვა ანგარიშისთვის, რომელსაც სისტემა რამდენიმე სერვისს შორის ინაწილებს, - არა.

გაიზიარე ჯგუფი. როცა ადამიანსაც და სერვისსაც ჩაწერა სჭირდება, ჩააყენე ისინი საერთო ჯგუფში და მთელ ხეს ჯგუფისთვის ჩაწერადი გახადე:

# a group for everyone who edits this server$ sudo groupadd gameadmins$ sudo usermod -aG gameadmins alice$ sudo usermod -aG gameadmins steam# hand the tree to the service user and the shared group$ sudo chown -R steam:gameadmins /srv/game$ sudo chmod -R g+rwX /srv/game# new files inside inherit the group, not the creator's own group$ sudo find /srv/game -type d -exec chmod g+s {} +

დიდი X ბრძანებაში g+rwX შესრულების უფლებას მხოლოდ საქაღალდეებს და იმ ფაილებს ამატებს, რომლებსაც უკვე ჰქონდათ, ამიტომ ყველა კონფიგურაციას შესრულებადად არ ხდის. g+s (setgid) ბიტი საქაღალდეებზე იმას ნიშნავს, რომ მასში შექმნილი ყველაფერი gameadmins-ს ეკუთვნის და არა იმას, ვინც შექმნა. ჯგუფის წევრობა შესვლისას იკითხება, ამიტომ alice-მ უნდა გამოვიდეს და თავიდან შევიდეს, რომ ძალაში შევიდეს - ეს ნაბიჯი გასაკვირად ბევრ დროს ართმევს ხალხს.

Setgid ჯგუფს ასწორებს და არა უფლებებს. თუ სერვისი ფაილებს მაინც 644-ით ქმნის, ისინი სწორ ჯგუფში იქნება, მაგრამ ჯგუფისთვის ჩაწერადი - არა. სერვისის umask დააყენე 002-ზე: systemd unit-ისთვის ეს არის UMask=0002 [Service] სექციაში, შემდეგ systemctl daemon-reload და გადატვირთვა. შენ მიერ ატვირთული ფაილებისთვის OpenSSH საშუალებას გაძლევს თავად SFTP სესიის umask დააყენო: sshd_config-ში ForceCommand internal-sftp -u 0002 ან Subsystem sftp internal-sftp -u 0002.

გამოიყენე ACL-ები, როცა ჯგუფური მოდელი უხერხული ხდება (რამდენიმე სერვისი, თითოეულს თავისი ხე). საქაღალდეზე default ACL ვრცელდება ყველაფერზე, რაც მასში მოგვიანებით შეიქმნება:

$ sudo setfacl -R -m u:alice:rwX /srv/game$ sudo setfacl -R -d -m u:alice:rwX /srv/game$ getfacl /srv/game/server.properties

ls -l-ში ACL-ები უფლებების ბოლოს +-ით ჩანს (-rw-rw-r--+), ბევრი SFTP კლიენტი კი მათ საერთოდ არ აჩვენებს. ეს უნდა გახსოვდეს, როცა ხილული უფლებები იმას ეწინააღმდეგება, რაც რეალურად ხდება.

რის გაკეთებაც არ შეიძლება: chmod -R 777. ის ყველა ფაილს ჩაწერადს ხდის მანქანაზე არსებული ყველა ანგარიშისა და ყველა გატეხილი პროცესისთვის, თან სერვისის მიერ შემდეგი ფაილის შექმნას მაინც ვერ გადაურჩება. მეორე ცუდი გამოსავალი - სერვისის root-ით გაშვება, რომ „ყველაფერში დაწეროს", განხილულია უფლებების სტატიის მფლობელობის განყოფილებაში, მოკლედ კი ასეა: მოწყვლადი plugin-ი მაშინ მთელ მანქანას დაეუფლება. რამდენიმე თამაშის სერვერი ერთ VDS-ზე აღწერს ერთი სერვერი - ერთი მომხმარებელი სქემას, რომელიც ამ ყველაფერს პროგნოზირებადს ხდის.

Chroot SFTP: საქაღალდე, სადაც ხვდები, შენი არ არის#

Chroot-ით დაცული SFTP გავრცელებულია shared და ხელით აწყობილ ჰოსტინგზე: მომხმარებელი ერთ დირექტორიაშია გამოკეტილი და სისტემის დანარჩენ ნაწილს ვერ ხედავს. ჩვეულებრივი კონფიგურაცია ასე გამოიყურება:

Match User alice    ChrootDirectory /srv/sftp/alice    ForceCommand internal-sftp    AllowTcpForwarding no    X11Forwarding no

OpenSSH მოითხოვს, რომ chroot დირექტორია და მის ზემოთ ყველა დირექტორია root-ს ეკუთვნოდეს და სხვა მომხმარებლისთვის ან ჯგუფისთვის ჩაწერადი არ იყოს. თუ ასე არ არის, შესვლა ჩავარდება და სერვერის auth log-ში გამოჩნდება bad ownership or modes for chroot directory. შედეგი chroot-ის კლასიკური საჩივარია: მომხმარებელი შედის, ხვდება /-ში და ვერაფერს ტვირთავს, რადგან / ციხის შიგნით root-ის დირექტორიაა, რომელშიც ჩაწერა მას დიზაინით ეკრძალება.

გამოსავალი ციხის შიგნით ჩაწერადი ქვედირექტორიაა:

$ sudo chown root:root /srv/sftp/alice$ sudo chmod 755 /srv/sftp/alice$ sudo mkdir /srv/sftp/alice/upload$ sudo chown alice:alice /srv/sftp/alice/upload

მერე მომხმარებლები /upload-ში წერენ. თუ ფაილები რეალურ აპლიკაციის საქაღალდემდე უნდა მივიდეს, symlink-ის მაგივრად bind mount გამოიყენე: ციხის გარეთ მიმართული symlink ციხის შიგნით გადაიყვანება და არსად მიდის.

მხოლოდ წასაკითხი mount-ები, სავსე დისკები და უცვლელი ფაილები#

ზოგჯერ უფლებებიც რიგზეა, მფლობელიც, და ჩაწერა მაინც ვერ ხერხდება. სამი მიზეზი უფლებებზე ღრმად არის.

მხოლოდ წასაკითხი ფაილური სისტემა. შეცდომაა Read-only file system (EROFS), თუმცა ზოგი SFTP კლიენტი მას ზოგად ჩავარდნად ან permission denied-ადაც კი აქცევს. შეამოწმე mount-ის პარამეტრები:

$ findmnt -no OPTIONS --target /srv/gamero,relatime

ტომი შეიძლება განზრახ იყოს ro-დ mount-ული (ქსელური საქაღალდე, ISO, container volume, რომელიც მხოლოდ წასაკითხად არის მიერთებული), მაგრამ ფაილური სისტემა, რომელიც გუშინ ჩაწერადი იყო და დღეს ro-ა, ჩვეულებრივ ნიშნავს, რომ kernel-მა დისკის შეცდომის აღმოჩენის შემდეგ ის თავიდან mount-ა. ეს აპარატურის ან ჰოსტის პრობლემაა და არა პარამეტრების; ნახე dmesg და ჩაწერა შეწყვიტე, სანამ მიზეზი არ გაირკვევა.

სავსე დისკი ან დამთავრებული inode-ები. ადგილის გარეშე ჩაწერა ვერ ხერხდება, და ბევრი კლიენტი ამას ცუდად აცნობებს - შეწყვეტილი ატვირთვა, შენახვის შემდეგ ნულოვანი ზომის ფაილი ან გაურკვეველი შეცდომა No space left on device-ის მაგივრად. შეამოწმე ბაიტებიც და inode-ებიც:

$ df -h /srv/game$ df -i /srv/game

ext4-ზე ერთი ნიუანსია: ბლოკების დაახლოებით 5% ნაგულისხმევად root-ისთვის არის დაცული. 96%-ზე სავსე დისკზე root პროცესს ჯერ კიდევ შეუძლია ჩაწერა, შენს მომხმარებელს კი - არა, და ეს ზუსტად უფლებების პრობლემას გავს. თამაშის სერვერის დისკი სავსეა გვიჩვენებს, როგორ იპოვო, რამ შეავსო.

უცვლელი ფაილი. chattr +i ფაილს root-ისთვისაც კი უცვლელს ხდის და შეცდომაა Operation not permitted. ზოგი ადმინი მას იმისთვის იყენებს, რომ თამაშმა კონფიგურაცია არ გადაწეროს, და მერე ივიწყებს. შეამოწმე და მოხსენი shell-იდან:

$ lsattr /srv/game/server.properties----i---------e------- /srv/game/server.properties$ sudo chattr -i /srv/game/server.properties

დისტრიბუციებზე, სადაც SELinux enforcing რეჟიმშია (Fedora, RHEL და მისი ასლები), კიდევ ერთი ფენაა: არასწორი უსაფრთხოების კონტექსტის მქონე ფაილზე უარი შეიძლება მაშინაც მოვიდეს, როცა უფლებები ნებას რთავს. ls -Z კონტექსტს აჩვენებს, ჩვეულებრივ დამნაშავეები კი ის ფაილებია, რომლებიც ადგილზე გადაიტანეს და არა დააკოპირეს.

რედაქტორები, რომლებიც დროებითი ფაილით ინახავენ#

გავრცელებული და გაუგებარი შემთხვევა: ფაილის გადაწერა ატვირთვით გამოდის, მაგრამ რედაქტორიდან შენახვა ვერა, ან პირიქით. მიზეზი ისაა, რომ „შენახვა" ერთი ოპერაცია არ არის. ბევრი ინსტრუმენტი ორიგინალის გვერდით ახალ ფაილს წერს და მერე მას ორიგინალზე გადაარქმევს, რომ გაწყვეტილმა კავშირმა ნახევრად ჩაწერილი კონფიგურაცია არ დატოვოს. ამას საქაღალდეზე სჭირდება w. თუ ფაილზე ჩაწერის უფლება გაქვს, მაგრამ მის საქაღალდეზე - არა, ადგილზე ჩაწერა გამოვა, დროებითი ფაილით შენახვა კი - არა.

WinSCP ატვირთვებისას ამას ნაგულისხმევად აკეთებს: ფაილი გადაიცემა როგორც name.filepart და დასრულებისას სახელი გადაერქმევა. პარამეტრი ნაპოვნია Preferences, Transfer, Endurance განყოფილებაში, როგორც „Enable transfer resume/transfer to temporary filename". Disable-ზე გადართვისას WinSCP პირდაპირ სამიზნე ფაილში წერს, რაც მუშაობს, როცა მხოლოდ ფაილია ჩაწერადი. ატვირთვის შემდეგ WinSCP ასევე ცდილობს უფლებებისა და დროის ნიშნულის დაყენებას; როცა ფაილში ჩაწერა შეუძლია, მაგრამ მის ატრიბუტებს ვერ ცვლის, იუწყება, რომ ატვირთვა წარმატებით დასრულდა, მაგრამ უფლებების ან დროის ნიშნულის დაყენება ვერ მოხერხდა. ატვირთვა მართლა შედგა. გადაცემის პარამეტრებში არის „Ignore permission errors", ან ამ კავშირისთვის მოხსენი „Set permissions" და „Preserve timestamp".

FileZilla ადგილზე წერს, ამიტომ დროებითი ფაილის პრობლემა იშვიათად ეხება; მისი „View/Edit" ლოკალურ ასლს ჩამოტვირთავს და შენახვისას თავიდან ტვირთავს, ანუ ეს ჩვეულებრივი ატვირთვაა ჩვეულებრივი წესებით. თუ FileZilla აჩვენებს open for write: permission denied-ს, ფაილი ან მისი საქაღალდე მართლა არ არის შენი მომხმარებლისთვის ჩაწერადი.

რედაქტორის დამატებები და სხვა ინსტრუმენტები განსხვავდება. VS Code-ის SFTP გაფართოებებს, Notepad++-ის plugin-ებსა და sshfs mount-ებს თითოეულს საკუთარი სტრატეგია აქვს, ზოგი შენახვისას ორიგინალი ფაილის უფლებების შენარჩუნებასაც ცდილობს. თუ ერთი ინსტრუმენტი ერთსა და იმავე ფაილზე მუშაობს და მეორე - არა, ჯერ დროებითი ფაილის ან ატრიბუტების განსხვავება ივარაუდე და მერე ის, რომ სერვერი შეიცვალა.

არის მეორე მახე საპირისპირო მიმართულებით: კლიენტმა, რომელიც ატვირთვისას ფიქსირებულ უფლებებს ადგენს, შეიძლება უჩუმრად შეცვალოს უფლებები. თუ სკრიპტი ყოველი ატვირთვისას შესრულების ბიტს კარგავს, სერვერის მაგივრად კლიენტის ატვირთვის უფლებების პარამეტრები შეამოწმე.

Pterodactyl-ის ტიპის თამაშების პანელზე#

Pterodactyl-ზე და Wings-ზე აგებული პანელები ფაილებისთვის OpenSSH-ს არ იყენებენ. Wings საკუთარ SFTP სერვისს უშვებს, მომხმარებლის სახელს სერვერის მოკლე id ემატება (alice.1a2b3c4d), პორტი ჩვეულებრივ 2022-ია და არა 22, და მის უკან shell არ არის. ყველა ფაილი იმ ერთ უპრივილეგიო მომხმარებელს ეკუთვნის, რომლითაც სერვერის container მუშაობს - სიებში ის container-ად ჩანს - და ყველაფერს, რასაც ატვირთავ, ეს მფლობელი ავტომატურად ენიჭება. ამიტომ root-ის შექმნილი ფაილების პრობლემა და „service user თუ ჩემი user" პრობლემა აქ არ ჩნდება. chown არ არის ხელმისაწვდომი და არც სჭირდება; chmod მუშაობს, მაგალითად სკრიპტზე 755-ის დასაყენებლად.

როცა პანელზე ჩაწერა ვერ ხერხდება, მიზეზები სხვაა:

Pterodactyl-ი ფაილებზე წვდომას ცალკე უფლებებად ყოფს - წაკითხვა, შიგთავსის წაკითხვა, შექმნა, განახლება, წაშლა, დაარქივება და თავად SFTP - და SFTP სერვისი იმავე უფლებებს ამოწმებს, რასაც ბრაუზერის ფაილების მენეჯერი. subuser, რომელსაც წაკითხვისა და SFTP-ის უფლება აქვს, მაგრამ update - არა, ზუსტად „დაკავშირებული ვარ, მაგრამ ვერ ვარედაქტირებ" სიტუაციაში ხვდება. სერვერის მფლობელი ამას ამ ადამიანის უფლებების შეცვლით ასწორებს და არა ფაილებში რამის შეცვლით. Subuser-ები და მინიმალური პრივილეგიები განიხილავს, ვის რა მივცეთ.

egg-ის ფაილების denylist პანელისთვის დამახასიათებელი მეორე მიზეზია. egg-ის ავტორს შეუძლია მონიშნოს ფაილები, რომელთა შეხებაც სერვერის მომხმარებლებს ეკრძალებათ (ხშირად ლიცენზიის ფაილი ან start სკრიპტი, რომელსაც ჰოსტი მართავს), და SFTP სერვისი მათ უფლებების შეცდომით უარყოფს სერვერის მფლობელისთვისაც კი. თუ ზუსტად ერთი ფაილი არის ყოველთვის უარყოფილი, მეზობლები კი - არა, პირველ რიგში ეს უნდა იეჭვო. Pterodactyl egg-ები თამაშის სერვერებისთვის განმარტავს, რას აკონტროლებს egg.

RE:NODE-ზე SFTP ყველა სერვერზე ხელმისაწვდომია, მონაცემები ანგარიშზე კი არა, თითოეულ სერვერზე გაიცემა, და კავშირის დეტალები პანელში სერვერზეა. სხვა ადამიანებისთვის წვდომა როლების, გუნდებისა და გრანტების გავლით მუშაობს ფაილების დეტალური უფლებებით, ამიტომ „მხოლოდ ფაილები, წაშლის გარეშე" რეალური პარამეტრია. როცა სერვერის დისკი ლიმიტს აღწევს, ჩაწერა ჩერდება; კონსოლის გრაფიკები დისკს ლიმიტთან ერთად აჩვენებს, რაც ამ მიზეზის დასადასტურებლად ან გამოსარიცხად ყველაზე სწრაფი გზაა. ფაილების გზამკვლევი ფაილების მენეჯერსა და SFTP-ს გვერდიგვერდ გადის, SFTP და ფაილების მენეჯერი კი კლიენტებს, სკრიპტით გადაცემებსა და იმ ფაილებს ეხება, რომლებსაც გაშვებული სერვერი ღიად ინახავს.

ჩამონათვალი, რომელიც ხუთ წუთში პოულობს მიზეზს#

ჩამოუყევი ამ სიას და გაჩერდი პირველივე არასწორ პუნქტზე:

1. ეს შესვლის შეცდომაა? Permission denied (publickey,password) ნიშნავს ავტორიზაციას და არა ფაილებს.
2. ყველა ფაილია უარყოფილი თუ ერთი? თუ ყველაფერი უარყოფილია, საქმე შენს ანგარიშშია, mount-ში ან დისკში. ერთი ფაილი კი იმ ფაილის მფლობელზე, უფლებებზე, უცვლელობის ნიშანზე ან პანელის denylist-ზე მიუთითებს.
3. ვინ ხარ და ვინ ფლობს მას? id, შემდეგ ls -la ფაილსა და მის საქაღალდეზე. შეადარე მფლობელი, ჯგუფი და ის ბიტები, რომლებიც შენზე მოქმედებს.
4. საქაღალდე ჩაწერადია? ახალი ფაილები, წაშლა, სახელის გადარქმევა და დროებითი ფაილით შენახვა - ყველას სჭირდება w დირექტორიაზე.
5. დისკი სავსეა ან მხოლოდ წასაკითხია? df -h, df -i, findmnt. პანელზე - დისკის გრაფიკი.
6. ფაილი უცვლელია? lsattr.
7. სხვა კლიენტი სხვანაირად იქცევა? თუ კი, ჩავარდნილ კლიენტში დროებითი ფაილით ატვირთვისა და ატრიბუტების პარამეტრები შეამოწმე.
8. პანელზე რა შეუძლია შენს ანგარიშს? სთხოვე მფლობელს შენი ფაილების უფლებების შემოწმება.

თითოეული ნაბიჯი ერთი ბრძანება ან ერთი ეკრანია, და თანმიმდევრობას მნიშვნელობა აქვს: ის იაფი და გავრცელებული მიზეზებიდან იშვიათებისკენ მიდის.

FAQ#

რატომ შემიძლია SFTP-ით ჩამოტვირთვა, მაგრამ ატვირთვა - არა?

ჩამოსატვირთად ფაილზე წაკითხვის უფლება გჭირდება, ასატვირთად კი - სამიზნე საქაღალდეზე ჩაწერის უფლება. ნაგულისხმევი უფლებები (644 ფაილებისთვის, 755 საქაღალდეებისთვის) წაკითხვას ყველას აძლევს, ჩაწერას კი - მხოლოდ მფლობელს. თუ იმ მომხმარებლისგან განსხვავებული მომხმარებლით შედიხარ, რომელიც საქაღალდეს ფლობს, ზუსტად ამას იღებ. შედი მფლობელით ან გაუზიარე მას ჯგუფი.

გამოასწორებს თუ არა chmod 777 SFTP permission denied-ს?

ის ხშირად სიმპტომს მალავს და ყოველთვის უფრო დიდ პრობლემას ქმნის. მაშინ მანქანაზე ყველა მომხმარებელსა და პროცესს ამ ფაილების გადაწერა შეუძლია, სერვისის მიერ შექმნილი ახალი ფაილები კი მაინც ჩვეულებრივი უფლებებით ჩნდება, ამიტომ პრობლემა ბრუნდება. სწორად ამას აგვარებს საერთო ჯგუფი setgid საქაღალდეებით და 002 umask.

რატომ ამბობს WinSCP, რომ ატვირთვა შედგა, მაგრამ უფლებების დაყენება ვერ მოხერხდა?

შეიძლება ფაილში ჩაწერა შეგეძლოს, მაგრამ მის ატრიბუტებს ვერ ცვლიდე, ჩვეულებრივ იმიტომ, რომ მისი მფლობელი არ ხარ. შიგთავსი აიტვირთა. ჩართე „Ignore permission errors" გადაცემის პარამეტრებში ან ამ საიტისთვის გამორთე WinSCP-ის მიერ ატვირთვისას უფლებებისა და დროის ნიშნულების დაყენება.

chroot ანგარიშით შესვლის შემდეგ root საქაღალდეში ვერ ვტვირთავ. გაფუჭებულია?

არა. OpenSSH მოითხოვს, რომ chroot დირექტორია root-ს ეკუთვნოდეს და მომხმარებლისთვის ჩაწერადი არ იყოს, ამიტომ ზედა დონე დიზაინით მხოლოდ წასაკითხია. შენმა ადმინისტრატორმა ციხის შიგნით უნდა შექმნას შენი მომხმარებლის საკუთრებაში მყოფი ქვედირექტორია და შენ იქ ატვირთავ.

რატომ შემიძლია პანელზე ზოგი ფაილის რედაქტირება და ზოგის - არა?

ან შენს subuser ანგარიშს ფაილების ზოგი უფლება აქვს და ზოგი - არა (მაგალითად, create update-ის გარეშე), ან ფაილი egg-ის denylist-შია. Pterodactyl-ზე დაფუძნებულ პანელზე მფლობელობა მიზეზი არ არის, რადგან სერვერის საქაღალდეში ყველა ფაილი ერთსა და იმავე container user-ს ეკუთვნის.

შეიძლება სავსე დისკმა გამოიწვიოს permission denied?

პირდაპირი გაგებით - არა, მაგრამ ბევრი SFTP კლიენტი ჩავარდნილ ჩაწერას ბუნდოვნად აცნობებს, ext4-ზე კი root-ისთვის დაცული ბლოკების გამო თითქმის სავსე დისკი ჩვეულებრივ მომხმარებლებს root-ზე ადრე უარს ეუბნება. უფლებების შეცვლამდე შეამოწმე df -h და df -i.