9

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
| improve this question | |
18

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).

| improve this answer | |
9

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.

| improve this answer | |
  • Could you perhaps do the same thing, but with LC_ALL=C exported into your environment instead? – user Sep 21 '17 at 19:01
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.

| improve this answer | |
  • 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
  • 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.

| improve this answer | |
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.