18

I've seen cases like that with faulty storage devices, with faults in remote storage (SAN, NAS), I think I've even seen something similar caused by mount permissions. But it's the first time I see this happening on the same filesystem as my home directory.

What kind of permissions are kicking in here? Definitely not mounts (I'm on the same ext4 filesystem), not SELinux, not ACLs. Then what?

I do not recall how this directory was created. It's likely it got created by some kind of software.

For me the weirdest part is that the directory is not even allowed to see its or its parent's info (last command).

I'm using Linux Mint Sarah.

user01@MyPC ~/somedirectory $ ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace

user01@MyPC ~/somedirectory $ ls -ld ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
drw-r--r-- 3 user01 user01 4096 Rgs 27  2016 ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:

user01@MyPC ~/somedirectory $ sudo file ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:: directory

user01@MyPC ~/somedirectory $ sudo ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
viso 4
drwxr-xr-x 3 user01 user01 4096 Rgs 27  2016 workspace

user01@MyPC ~/somedirectory $ sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937216     Links: 3
Access: (0644/drw-r--r--)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:57:33.990819052 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2017-03-13 14:56:40.960468954 +0200
 Birth: -

user01@MyPC ~/somedirectory $ sudo getfacl ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
# file: deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:
# owner: user01
# group: user01
user::rw-
group::r--
other::r--

user01@MyPC ~/somedirectory $ stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937216     Links: 3
Access: (0644/drw-r--r--)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:57:33.990819052 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2017-03-13 14:56:40.960468954 +0200
 Birth: -

user01@MyPC ~/somedirectory $ stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
stat: nepavyksta patikrinti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied

user01@MyPC ~/somedirectory $ sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937217     Links: 3
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:58:46.845727190 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2016-12-02 13:56:08.298109826 +0200
 Birth: -

user01@MyPC ~/somedirectory $ stat .
  File: '.'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3278479     Links: 23
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 09:46:22.102269130 +0300
Modify: 2017-09-20 17:33:04.564009275 +0300
Change: 2017-09-20 17:33:04.564009275 +0300
 Birth: -

user01@MyPC ~/somedirectory $ ll ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/.': Permission denied
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/..': Permission denied
viso 0
d????????? ? ? ? ?            ? ./
d????????? ? ? ? ?            ? ../
d????????? ? ? ? ?            ? workspace/

Attributes:

user01@MyPC ~/somedirectory $ sudo lsattr ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/
-------------e-- ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace
user01@MyPC ~/somedirectory $ sudo lsattr ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
-------------e-- ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace/directory2
fra-san
  • 10,205
  • 2
  • 22
  • 43
netikras
  • 425
  • 2
  • 4
  • 9

6 Answers6

32

On files read suffices to check the permissions. You need read AND execute on folders to ls them. 

chmod -R a+X ./deploy_dir

Capital X to only set execute on folders (and files that already have execute bit set).

HoD
  • 496
  • 6
    I once spent half a day on a similar issue, it's easy to miss! – HoD Sep 21 '17 at 11:04
  • In general I'd advise to investigate the reason for the corruption carefully first, then try to fix that. There is a possibility that you make things worse otherwise. – U. Windl Mar 07 '22 at 12:28
11

Reading the permissions of a file requires calling stat(2) on it, and that requires the execute/access permission on the containing directory (all directories in the path). This is actually the same with every other system call that takes a filename. However, reading the contents of a directory (the list of file names) only requires read access on the directory.

In your sample snippet:

~/somedirectory $ ls -l .../bin/D\:
ls: negaliu pasiekti '.../bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace

ls tried to call stat(".../bin/D:/workspace"), got an error and complained. On some systems you can get partial information from the readdir/getdents calls along with the file names, without needing to use stat. Like here, workspace is shown to be a directory.

And here we see there's no x bit for any user:

~/somedirectory $ ls -ld .../bin/D\:
drw-r--r-- 3 user01 user01 4096 Rgs 27  2016 .../bin/D:

As root, you get a full listing, since being root ignores the permission bits entirely.

ilkkachu
  • 138,973
  • Could you perhaps do the same thing, but with LC_ALL=C exported into your environment instead? – user Sep 21 '17 at 19:01
  • That can of course happen for other reasons than lack of execute permissions, the "partial information" (if present) is always just the type of the file and nothing more, and the "some systems" are actually Linux and BSDs (when using a mainstream fs and not minixfs, ntfs, squashfs, etc) –  Nov 03 '21 at 10:18
  • And yeah, that could also happen when you're root. –  Nov 03 '21 at 10:20
  • @UncleBilly, it can happen for other reasons too, but here, the case is quite clear: based on the listings in the question, it's about the permissions. I don't know about each and every Unix-like system, so I can't know if it's just Linux and the BSDs that provide additional non-standard information in struct dirent. Also of course it requires support from the utility, e.g. the Busybox version of ls I tried just throws errors when it tries to call stat() on the files, and the one on Mac lists the names with ls dir/ but nothing with ls -l dir/, not even errors. – ilkkachu Nov 03 '21 at 10:28
  • And in the Q here, it didn't happen as root. – ilkkachu Nov 03 '21 at 10:28
  • Yes, and that's a behaviour specific to GNU ls, I forgot that. Since you're redirecting all the similar Q&A here (notice that non logged-in users coming from search results are always automatically redirected unless they manually add ?noredirect=1 to the url) you should add all the possible details and permutations, without hedgings. –  Nov 03 '21 at 10:34
  • @UncleBilly, if you're referring to this https://unix.stackexchange.com/questions/675364/what-does-the-output-d-in-ls-l-mean, note that the user themself said it looked like a duplicate (in a now-deleted comment...), and accepted it as such (at least that's what I've understood causes Community to show up in the list). It's not like I single-handedly did it. – ilkkachu Nov 03 '21 at 10:50
  • If such a redirection happens, that's indeed bad, not just in this case. But at least as I just tested, I don't see it happen, I just get the Q and answers with a smaller banner linking to the other Q. Not sure what affects that. Anyway, you can always vote to reopen? – ilkkachu Nov 03 '21 at 10:51
  • @UncleBilly, this is how that question looks to me, when not logged in, coming from a google search: https://i.stack.imgur.com/dDcQF.png (Also note that there's another answer on this page that also only addresses the permissions case, it's even shown higher than this one.) – ilkkachu Nov 03 '21 at 17:44
1

In order to look at file attributes one needs the right to read the directory. If this is not possible, question marks will be shown.

For the reason why that user cannot read the information, look at the attributes of the directory (.../D:/. above). Another possible cause would be if the directory has been removed or is inaccessible (e.g. network file system, stale handle) for a different reason than access modes.

Ned64
  • 8,726
  • Updated the question. Attributes are all the same of the D:, its children, its parent ant my ~/. directory. – netikras Sep 21 '17 at 10:42
  • And this directory has been there for months now. It's not disappearing anywhere. It's clearly telling that unless I am root I cannot go inside :/ That wouldn't work with flapping media or filehandles I think – netikras Sep 21 '17 at 10:44
  • Please try to check all parent directories, too, if any of those has attributes that create problems (see whether ll fails as user01 on any parent down to root). No need to post the output, just tell us the result please. – Ned64 Sep 21 '17 at 10:48
  • What you could to is examine (maybe not post, because of the size) the output of strace stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/ and look exactly which system call fails. – Ned64 Sep 21 '17 at 10:50
  • 1
    I've just tar'ed the directory, scp'ed it to another server and did the same ls test. The result is identical – netikras Sep 21 '17 at 10:59
  • 2
    You do not the x flag, so HoD is right. I had not seen that in your cluttered output. strace would have told you that. too. – Ned64 Sep 21 '17 at 11:00
1

Today I had a very similar issue, with similar symptoms: question marks in the permissions and ownership fields, and even with root/sudo I was not able to change any of this. Then I finally remembered that this particular directory was actually the mount point to a directory on Windows file share, which I had set up a few weeks ago (in a trial session to see if Samba/CIFS is any good for my project) and apparently it got unmounted in the meantime. After reissuing the mount.cifs command and entering my credentials for the Windows part of our network, 'ls' reported normal permission and ownership information on the directory. Since the symptoms looked exactly like yours, I wonder if you are in a similar situation, also because "D:" looks very Windows-ish.

davino
  • 26
  • Hi, the green tick means the user who asked the question has marked the answer as "accepted". Therefore we can at least assume the permissions were able to be changed using chmod. This directory is underneath the users home directory (~). Plus they are already aware that issues like this can be due to mount issues with remote storage. – sourcejedi Feb 12 '19 at 13:32
  • Note also, the stat command confirms this. Compare the Device field for stat . v.s. sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D: File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:'`. It is the same. This output is good evidence that they are on the same filesystem. – sourcejedi Feb 12 '19 at 13:35
  • Ah, right! Sorry for the noise... – davino Feb 12 '19 at 14:58
0

My solution:

$ sudo mount -v | grep mount_point

This displays the mount_point's mounted file systems and showed my mount point was still mounted even though nothing was showing.

$ umount -f mount_point

The directory permissions and permissions now show correctly.

AdminBee
  • 22,803
user491645
  • 1
0

I had the same problem. It was a syntax error in the /etc/auto.disk file on mount options.

Greenonline
  • 1,851
  • 7
  • 17
  • 23
Mechano
  • 26
  • Do you mean /etc/auto.disks, with an s at the end? If you google auto.disk then nothing shows up, whereas auto.disks yields some results. Also, could you [edit[ and expand upon the answer and state what the syntax error actually was? – Greenonline Mar 05 '22 at 08:03
  • You can use whatever you want also auto.jack It.s importanti you put the right file name into auto.master

    /- /etc/auto.disk --timeout=10,defaults,user,exec

     – Mechano Mar 06 '22 at 12:30