Skip to content

Instantly share code, notes, and snippets.

Grzegorz Wierzowiecki gwpl

Block or report user

Report or block gwpl

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@gwpl
gwpl / NEW QGROUP!.md
Created Dec 15, 2017 — forked from mazgi/NEW QGROUP!.md
Btrfs subvolume quota
View NEW QGROUP!.md
[root@btrfs-testdrive] # btrfs qgroup create 1/100 /mnt/btrfs
[root@btrfs-testdrive] # btrfs qgroup assign 0/276 1/100 /mnt/btrfs
[root@btrfs-testdrive] # btrfs qgroup show /mnt/btrfs
qgroupid rfer       excl       
-------- ----       ----       
0/5      16384      16384      
0/256    2864136192 2864136192 
0/258    833703936  833703936  
0/259    52510720   52510720   
@gwpl
gwpl / SSH-X11-Forwarding.md
Created Dec 15, 2011 — forked from adrianratnapala/SSH-X11-Forwarding.md
A note on X11-Forwarding in SSh.
View SSH-X11-Forwarding.md

I used to think that

ssh -X me@some.box

"just bloody worked". However this might not work - ssh must play ball on both sides of the link. On the remote (ssh server, X client) sshd must sit behind some port, tell Xlib to send X11 requests to it and then forward them back to you the X server (where the ssh client is). If the remote box is locked down to prevent this, you will get:

X11 forwarding request failed on channel 0

as part of an otherwise working login. As it happens, I am the admin of the remote box in question, so I followed the ArchWiki and went to /etc/ssh/sshd_config and uncommented

You can’t perform that action at this time.