From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10070 invoked by alias); 1 Oct 2018 16:47:47 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 9453 invoked by uid 89); 1 Oct 2018 16:47:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*Ad:D*gov, reside, Notice, mount X-HELO: blaine.gmane.org Received: from Unknown (HELO blaine.gmane.org) (195.159.176.226) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 Oct 2018 16:47:45 +0000 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1g71K2-0004gO-LL for cygwin@cygwin.com; Mon, 01 Oct 2018 18:45:26 +0200 To: cygwin@cygwin.com From: Andrew Schulman Subject: Re: Cannot use screen when Cygwin is installed on a FAT32 filesystem / chmod does not work on FAT32 directories Date: Mon, 01 Oct 2018 16:47:00 -0000 Message-ID: <0ui4rddofohlrf2bvo740skq2uo78c15up@4ax.com> References: <86050286-eb1a-2366-54a4-2cc822a905b5@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00005.txt.bz2 > I'm trying to use Cygwin on a Windows machine with the latest release. > The system in question must run from a filesystem formatted with FAT32 > and therefore inherits the 'noacl' field according to the documentation. > > After a clean install and running Cygwin.bat, I am greeted with the > following error when attempting to call 'screen -ls': > > > $ screen -ls > > Directory /tmp/uscreens/S-MyUserName must have mode 700. > > Note that at this point the /tmp/uscreens directory has been created for > the first time. > > Closing this terminal, reopening it, and calling 'screen -ls' again > results in the following error: > > > $ screen -ls > > Directory '/tmp/uscreens' must have mode 777. > > The problem is that screen requires that the /tmp/uscreens directory > have mode 777. This directory is already accessible to 'Everyone' with > all permissions but is recognized only as 'drwxr-xr-x' (755). This > appears to be an issue specifically with how permissions are displayed > on a FAT32 drive as I can confirm that I have never had this issue on an > NTFS filesystem with the 'noacl' flag specified in fstab. > > I thought that I could workaround this by simply patching these checks > out so I downloaded the source and removing the offending lines: > > > if (((int)st.st_mode & 0777) != n) > > Panic(0, "Directory '%s' must have mode %03o.", SockDir, n); > .. > > if ((st.st_mode & 0777) != 0700) > > Panic(0, "Directory %s must have mode 700.", SockPath); > > This allows screen to run and for screens to be created. But now it > fails to list any screens. > > When no screens exist I get the following output: > > > $ screen -ls > > No Sockets found in /tmp/uscreens/S-MyUserName > > And when screens exists: > > > $ screen -ls > > There is a screen on: > > 1 Socket in /tmp/uscreens/S-MyUserName > > Notice that a screen is detected (the output is formatted correctly) but > the screens are not populated in the list. > > I'm thinking that this new problem may reside within socket.c of > screen's source code but I'm not sure. Hi. I'm the screen maintainer for Cygwin. FAT32 isn't used much any more, so it's been a long time since I've heard of this problem. But below is the note I wrote about it in /usr/share/doc/screen/README.Cygwin, maybe 10 years ago. The problem people were having then was that screen would start, but after they detached their sessions, they couldn't reattach to them again. The recommendation below is either to set SCREENDIR in your environment to point to some directory on an NTFS file system where screen can store its socket files, or to mount an NTFS file system on /tmp. If that's not an option for you, then yes, I guess it should be possible to patch the source code to ignore the permissions and use the sockets anyway. It looks as though you've done half of that - screen will start and put its sockets there, but again it won't reattach to them later. Maybe if you find the other part in the code where it checks permissions to list or reattach to sockets, and take the permission checks out, it'll work. I'm sorry I don't have any time to spend on that myself, but if you get it to work, I'll be glad to consider the patch. Good luck! Andrew FAT file system warning: If your /tmp directory is stored on a FAT file system, you won't be able to reattach to screen sessions after you detach from them. The reason is that to preserve the security of your session, screen requires that restrictive permissions be set on the directory where it stores its socket files, in /tmp/uscreens by default. But the FAT file system doesn't support file permissions at all, so it's incapable of setting the permissions tightly enough. If this is your case, then when you try to reattach to a detached session, screen will give you the following unhelpful error message: There is a screen on: There is no screen to be resumed. You can use the 'mount' command to see which type of file system your root directory is stored on: mount | grep 'on / ' (or mount | grep 'on /tmp ' in case you've mounted a separate file system on /tmp). If the result says the type is fat, fat32, vfat, or some other kind of fat, then you won't be able to reattach to screen sessions. To solve this problem, you need to tell screen to store its socket files in a directory on a file system that does support file permissions, such as NTFS. For example, you could put the following in your ~/.bash_login file: export SCREENDIR=/cygdrive/c/WINDOWS/Temp/screen/$USER assuming that C:/Windows/Temp/screen/$USER is an existing NTFS directory where you have write permission. Another solution would be to mount an NTFS directory as your /tmp directory, e.g. by putting C:/WINDOWS/Temp /tmp some_fs binary 0 0 into /etc/fstab or /etc/fstab.d/$USER. See mount(1). For discussion of this problem, plus some bo[ng]us arguments about the Romans, see http://thread.gmane.org/gmane.os.cygwin/126639. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple