RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1634057 - [FutureFeature] Nautilus should be able to display expanded permissions/ownership details if unix extensions are available
Summary: [FutureFeature] Nautilus should be able to display expanded permissions/owner...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: samba
Version: 8.4
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.4
Assignee: Andreas Schneider
QA Contact: sssd-qe
URL:
Whiteboard: blocked
Depends On:
Blocks: 1788833
TreeView+ depends on / blocked
 
Reported: 2018-09-28 15:23 UTC by Joe Wright
Modified: 2022-09-16 08:18 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-16 08:18:50 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screenshot of permissions reported by libsmbclient vs real values (123.29 KB, image/png)
2018-12-14 16:46 UTC, Ondrej Holy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Samba Project 14101 0 None None None 2019-08-23 12:16:07 UTC

Description Joe Wright 2018-09-28 15:23:22 UTC
Description of problem:
- nautilus does not display expanded permissions/ownership details on SMBv1 filesystems. All entries (owner, group, r/w/x) show as "unknown". Access privileges are still correctly enforced. Permissions correctly show when examining the mounted SMBv1 filesystem from the command line


Version-Release number of selected component (if applicable):
- nautilus-3.22.3-5.el7.x86_64
- gvfs-smb-1.30.4-5.el7.x86_64
- libsmbclient-4.7.1-6.el7.x86_64

How reproducible:
- 100% by customer

Steps to Reproduce:
1. configure nautilus to us SMBv1
2. Access a SMBv1 share
3.

Actual results:
- permissions fields show "unknown" 

Expected results:
- permissions information is displayed

Additional info:

Comment 4 Ondrej Holy 2018-12-07 15:56:41 UTC
This seems to be gvfs, or libsmbclient issue. Those values are probably based on G_FILE_ATTRIBUTE_UNIX_MODE in Nautilus, but this attribute is not set by the backend. Support for this attribute was removed from the backend, because this was not reliable for some reason:
https://gitlab.gnome.org/GNOME/gvfs/blob/master/daemon/gvfsbackendsmb.c#L1486
https://gitlab.gnome.org/GNOME/gvfs/commit/1ba87b47bf824b1afaed84931c3e8252e248e45c

This needs further investigation... Andreas, don't you have any comments here?

Comment 6 Ondrej Holy 2018-12-14 16:46:32 UTC
Created attachment 1514409 [details]
screenshot of permissions reported by libsmbclient vs real values

I've made a simple test to see whether statbuf->st_mode/st_uid/st_gid provided by smbc_stat() could be used to display the requested permissions (I've just basically partially reverted the https://gitlab.gnome.org/GNOME/gvfs/commit/1ba87b47bf824b1afaed84931c3e8252e248e45c). But obviously it is not possible, libsmbclients reports 644 mode for all files and uid/gid is probably based on the gid()/uid() from the client, see screenshot. So I am going to change the component to samba, because libsmbclient doesn't provide the real values...

Comment 11 Andreas Schneider 2019-06-28 08:45:48 UTC
libsmbclient can only show uid/gid and permissions correctly if it connect to a Samba server offering unix extensions and those need to be turned on server-side.

Are 'unix extensions' configured on the server?

Comment 12 Andreas Schneider 2019-08-06 14:04:29 UTC
Ping!

Comment 13 Ondrej Holy 2019-08-07 14:12:12 UTC
Ok, I've explicitly added "unix extensions = yes" and "protocol = NT1" and tried again to be sure. The stat call in smbclient interface shows correct permissions, however, the situation on gvfs-side is still the same. st->st_mode returned by smbc_stat() is wrong. Is there any way to check from gvfs over libsmbclient whether the unix extensions are in use?

Comment 21 Andreas Schneider 2020-04-30 15:15:39 UTC
I'm sorry, but this can't be fixed in RHEL7. The fix is much more complex than first thought. We will only be able to fix that in a future RHEL8 release.

Comment 24 Andreas Schneider 2020-06-30 06:59:03 UTC
This can only be achieved with SMB3 unix extensions.

Comment 30 Andreas Schneider 2022-09-16 08:18:50 UTC
This can't be implemented with SMB1, we need SMB3 posix extensions.


Note You need to log in before you can comment on or make changes to this bug.