[16:01:11] Hello. I have done something wrong and now I cannot access files due to an permission error. Could someone please help me? [16:01:54] try with sudo (re @wmtelegram_bot: Hello. I have done something wrong and now I cannot access files due to an permission error. Could someone plea...) [16:02:49] okey, i try it [16:05:44] Sorry, user syunsyunminmin is not allowed to execute '/usr/bin/rm data/logs -r' as root on tools-bastion-13.tools.eqiad1.wikimedia.cloud. [16:07:08] which tool are you working with? [16:07:49] and which files? (I don’t see data/logs in your home directory) [16:08:31] i'm in my home directory/discordbot [16:08:38] must be under `/` [16:09:24] as far as I can tell everything in there is owned by syunsyunminmin, so I think you should still be able to delete it (without sudo) [16:18:57] Oh, I was able to delete the home directory's before I knew it. [16:21:15] But I have same problem in ~tools.syunminbot/discordbot/data [16:22:25] which command are you running and which error do you get? [16:22:38] I see some strange permissions in there but it all still seems to be owned by tools.syunminbot AFAICT [16:23:45] rm data -r [16:23:45] rm: descend into write-protected directory 'data'? yes [16:23:46] rm: cannot remove 'data/proxydata.json': Permission denied [16:23:46] rm: cannot remove 'data/logs': Permission denied [16:23:47] rm: remove write-protected directory 'data'? yes [16:23:47] rm: cannot remove 'data': Directory not empty [16:24:44] and you’re running this as the tool account? or as syunsyunminmin? [16:25:23] what is tool acount [16:25:40] the syunminbot account [16:25:43] I became syunminbot [16:25:49] yes, that’s what I mean [16:26:11] so if you run `whoami` it should say `tools.syunminbot` [16:26:47] tools.syunminbot@tools-bastion-13:~/discordbot$ whoami [16:26:48] tools.syunminbot [16:27:21] yes i have already syunminbot [16:27:54] that’s strange, I don’t know why you can’t delete it then [16:30:45] ohh [16:30:51] the directory is missing execute permission [16:31:34] try `chmod u+x data` first [16:31:42] (and probably `chmod u+x data/logs` too) [16:32:38] ohh, i can delete it! [16:32:47] thank you so much! [16:33:30] \o/ [18:13:26] !log lucaswerkmeister@tools-bastion-13 tools.wd-image-positions deployed 01d9085f1a (upgrade toolforge_i18n to 0.0.2; also upgrade pip from 24.0 to 24.1.1) [18:13:29] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wd-image-positions/SAL [18:22:28] !log lucaswerkmeister@tools-bastion-13 tools.lexeme-forms deployed f3b3981ec9 (upgrade toolforge_i18n to 0.0.2; also upgrade pip from 24.0 to 24.1.1) [18:22:31] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [18:54:03] Hi, is anyone around who might point me in the right direction? https://refill.toolforge.org/ has started returning a 403 today for no obvious reason and I am not sure how to go about troubleshooting it. I would normally rely on TheresNoTime for this but I don't think they're around at the moment. [18:57:39] !help [18:57:39] If you don't get a response in 15-30 minutes, please email the cloud@ mailing list -- https://wikitech.wikimedia.org/wiki/Help:Cloud_Services_communication [18:58:04] hm, there’s two pods in `kubectl get pods` [18:58:19] one with status Terminating [18:58:26] and `kubectl get events` has some errors about failing to stop containers [19:04:04] hm, if I SSH into tools-k8s-worker-nfs-53.tools.eqiad1.wikimedia.cloud I can see a few refill processes (and a few htop processes) stuck in D state [19:04:14] which feels like the kind of NFS issue that occasionally warrants a reboot, e.g. https://sal.toolforge.org/log/nY0JTJABxE1_1c7sMSSK [19:04:24] but I don’t think I feel confident enough to do that myself [19:04:47] so I’m hoping someone else is around who can also look into it :| [19:12:33] thanks for the reply lucas, that provides me with a useful starting point [19:12:55] (also, oops, I meant lsof processes not htop processes above ^^) [19:13:04] good luck…