Bug 1634057

Summary: [FutureFeature] Nautilus should be able to display expanded permissions/ownership details if unix extensions are available
Product: Red Hat Enterprise Linux 8 Reporter: Joe Wright <jwright>
Component: sambaAssignee: Andreas Schneider <asn>
Status: CLOSED WONTFIX QA Contact: sssd-qe <sssd-qe>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.4CC: aboscatt, alanm, amike, asn, bgollahe, bhodges, dpal, gdeschner, jarrpa, jstephen, kwalker, oholy, thalman, tpelka
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: 8.4   
Hardware: x86_64   
OS: Linux   
Whiteboard: blocked
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-09-16 08:18:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1788833    
Attachments:
Description Flags
screenshot of permissions reported by libsmbclient vs real values none

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.