Re: mount -t cifs ... -o username=... file_mode=0777 ignored
This thread has now degenerated into political diatribe & irrelevant
asides, and has ceased to come even close to providing any useful
technical response to the original request. Furthermore, the original
poster has already posted his workaround solution.
So, can we PLEASE put this thread to rest?!
Thanks,
Gilbert
On 2021-08-18 10:57 a.m., Yasha Karant wrote:
These are NOT my demands -- these are standard ergonomic engineering
approaches. This is why the operation of a road vehicle is the same in
all modern vehicles -- save for upon which side of the road one drives
("right" vs "left" hand). As a counter example, one of my colleagues
has been using MS Office XP for a long time. She was forced to convert
to a later MS Office, and the controls have changed -- as she stated
"why did they hide the open dialog, and the word count is moved to a
completely different ... ". Thus, I use MATE and sometimes an actual
terminal (not a GUI) CLI interface, neither the current Gnome nor KDE
(originally, an interface "clone" of Unix CDE). For CIFS, it appears
that there is no equivalent of MATE for "traditional unix/bsd/linux
commands". There are well understood reasons for a significant change
in a control interface -- motor vehicles need a different interface than
a "beast of burden" drawn vehicle, the invention of saddle and stirrups
made major improvements to horse riding (but there a still persons who
use the older technology).
Re: mount -t cifs ... -o username=... file_mode=0777 ignored
These are NOT my demands -- these are standard ergonomic engineering
approaches. This is why the operation of a road vehicle is the same in
all modern vehicles -- save for upon which side of the road one drives
("right" vs "left" hand). As a counter example, one of my colleagues
has been using MS Office XP for a long time. She was forced to convert
to a later MS Office, and the controls have changed -- as she stated
"why did they hide the open dialog, and the word count is moved to a
completely different ... ". Thus, I use MATE and sometimes an actual
terminal (not a GUI) CLI interface, neither the current Gnome nor KDE
(originally, an interface "clone" of Unix CDE). For CIFS, it appears
that there is no equivalent of MATE for "traditional unix/bsd/linux
commands". There are well understood reasons for a significant change
in a control interface -- motor vehicles need a different interface than
a "beast of burden" drawn vehicle, the invention of saddle and stirrups
made major improvements to horse riding (but there a still persons who
use the older technology).
On 8/18/21 03:36, Nico Kadel-Garcia wrote:
On Wed, Aug 18, 2021 at 2:10 AM Yasha Karant wrote:
Although I was not involved with the specification of CIFS, nor with the
design or implementation of CIFS on open systems, I respectfully
disagree with at least some of your conclusions. In a top-down entity
Then your demands should not carry much weight. I've been porting
Samba and related tools to UNIX systems since roughly 1993, and I can
tell you that mapping the permissions of the underlying filesystems
which SMB and later CIFS were designed to emulate into the Linux world
is and will remain awkward. The UNIX and Linux authors who wrote
Samba, the ancestor toolkit to cifs-utils, to did not design CIFS or
its ancestor SMB. Microsoft did. Mapping UID and GID to idmaps, and
handling the hierarchy of permissions, is a pain in the keister and
the complexities often ignored as unwelcome or undesirable in a UNIX
environment.
If you don't like an architectural selection by the authors of
cifs-utils, or Red Hat's or SuSE's architecteral implementaitons, hop
over to the Samba mailing lists where the subtleties of CIFS are a
better subject. SL is just a rebuild of RHEL: you might take it up
with Red Hat. It's not fair to kvetch at Scientific Linux supporters
about it.
(totalitarian dictatorship, clandestine or military service,
corporation, authoritarian theocracy, etc), the designated decision
maker/s decides as to what is allowed or not, including not permitting
backward compatibility. Would ignoring a protection mode enhance
Input saying "you shoulda aughta done it this way" bears very little
weight compared to that of actually picking up the tools, reviewing
the issue, and seeing if it works. cifs-utils used to be part of
Samba, and got factored out for good reasons, but has in general been
very well behaved. It's working well in literally millions of devices
around the world. If you or someone else with CIFS issues has a
problem, I'll recommend the Samba mailing lists.
security by imposing a different access and security model? Perhaps, or
even definitely yes. However, the fact stated by the posting person
that SuSE did emulate a perhaps-obsolete security model under a
subsequent security model does seem to indicate that SuSE had a more
universal implementation of backward compatibility than what was
observed with EL. If the posting was in error and SuSE does not permit
such backward compatibility (perhaps with a warning message), then SuSE
as well as EL is not backward compatible.
SuSE... has made some strange architectural decisions at various
times. Rather than holding forth on the moral and intellectual
failures of people you've not met or tried to collaborate with,
perhaps you could grab a VM and actually try it. Contribute to the
understanding, rather than decry someone else's work.
Me? I've got samba backporting for RHEL 7 and RHEL 8 public repos to
update. I'm hoping they've gotten the MIT Kerberos integration
straightened out enough to use for RHEL effectively. I've not been
backporting it to SL because there's not going to be an SL 8.
Re: mount -t cifs ... -o username=... file_mode=0777 ignored
On Wed, Aug 18, 2021 at 2:10 AM Yasha Karant wrote: > > Although I was not involved with the specification of CIFS, nor with the > design or implementation of CIFS on open systems, I respectfully > disagree with at least some of your conclusions. In a top-down entity Then your demands should not carry much weight. I've been porting Samba and related tools to UNIX systems since roughly 1993, and I can tell you that mapping the permissions of the underlying filesystems which SMB and later CIFS were designed to emulate into the Linux world is and will remain awkward. The UNIX and Linux authors who wrote Samba, the ancestor toolkit to cifs-utils, to did not design CIFS or its ancestor SMB. Microsoft did. Mapping UID and GID to idmaps, and handling the hierarchy of permissions, is a pain in the keister and the complexities often ignored as unwelcome or undesirable in a UNIX environment. If you don't like an architectural selection by the authors of cifs-utils, or Red Hat's or SuSE's architecteral implementaitons, hop over to the Samba mailing lists where the subtleties of CIFS are a better subject. SL is just a rebuild of RHEL: you might take it up with Red Hat. It's not fair to kvetch at Scientific Linux supporters about it. > (totalitarian dictatorship, clandestine or military service, > corporation, authoritarian theocracy, etc), the designated decision > maker/s decides as to what is allowed or not, including not permitting > backward compatibility. Would ignoring a protection mode enhance Input saying "you shoulda aughta done it this way" bears very little weight compared to that of actually picking up the tools, reviewing the issue, and seeing if it works. cifs-utils used to be part of Samba, and got factored out for good reasons, but has in general been very well behaved. It's working well in literally millions of devices around the world. If you or someone else with CIFS issues has a problem, I'll recommend the Samba mailing lists. > security by imposing a different access and security model? Perhaps, or > even definitely yes. However, the fact stated by the posting person > that SuSE did emulate a perhaps-obsolete security model under a > subsequent security model does seem to indicate that SuSE had a more > universal implementation of backward compatibility than what was > observed with EL. If the posting was in error and SuSE does not permit > such backward compatibility (perhaps with a warning message), then SuSE > as well as EL is not backward compatible. SuSE... has made some strange architectural decisions at various times. Rather than holding forth on the moral and intellectual failures of people you've not met or tried to collaborate with, perhaps you could grab a VM and actually try it. Contribute to the understanding, rather than decry someone else's work. Me? I've got samba backporting for RHEL 7 and RHEL 8 public repos to update. I'm hoping they've gotten the MIT Kerberos integration straightened out enough to use for RHEL effectively. I've not been backporting it to SL because there's not going to be an SL 8.
Re: mount -t cifs ... -o username=... file_mode=0777 ignored
Thank you to all here! Solved: 1. folder DCIM copy to SL filesytem. 2 a ssh -command to linux client with SD-card purges "DCIM" folder. :) Am 18.08.21 um 05:56 schrieb Nico Kadel-Garcia: On Tue, Aug 17, 2021 at 11:21 AM Yasha Karant wrote: This is a poor design decision on the part of the Linux systems implementers, as it breaks backward compatibility. There is no reason that an "auto-translator" from CIFS to what has been used in unix/BSD/linux for a very long time should not have been implemented.
Re: mount -t cifs ... -o username=... file_mode=0777 ignored
Although I was not involved with the specification of CIFS, nor with the design or implementation of CIFS on open systems, I respectfully disagree with at least some of your conclusions. In a top-down entity (totalitarian dictatorship, clandestine or military service, corporation, authoritarian theocracy, etc), the designated decision maker/s decides as to what is allowed or not, including not permitting backward compatibility. Would ignoring a protection mode enhance security by imposing a different access and security model? Perhaps, or even definitely yes. However, the fact stated by the posting person that SuSE did emulate a perhaps-obsolete security model under a subsequent security model does seem to indicate that SuSE had a more universal implementation of backward compatibility than what was observed with EL. If the posting was in error and SuSE does not permit such backward compatibility (perhaps with a warning message), then SuSE as well as EL is not backward compatible. On 8/17/21 8:56 PM, Nico Kadel-Garcia wrote: On Tue, Aug 17, 2021 at 11:21 AM Yasha Karant wrote: This is a poor design decision on the part of the Linux systems implementers, as it breaks backward compatibility. There is no reason that an "auto-translator" from CIFS to what has been used in unix/BSD/linux for a very long time should not have been implemented. Please do not say why work should have been done that you haven't tried to do yourself. CIFS, for example, supports multiple layers of both username and group based permissions, with more complex inheritance, ordered layers of "permit" and "deny" for each user or group, and considerable awkwardness resolving them that costs development, time, resources, and can cost a lot of tearing out of hair when trying to transform it to POSIX style permissions. CIFS was not designed for UNIX. It was designed for Windows file-sharing, which has quite a few different distinctions due to the previous VFAT or more modern NTFS filesystems which underly windows filesystems and their capabilities. NFSv4 ACL's come close to these permissions, but managing those in the Linux world is a serious pain in the ass. Samba does a pretty good of transforming underlying POSIX filesystems into CIFS compatible access, Although this practice is not uncommon in the profiteer sector as planned obsolescence for cash flow and other fiscal measures dominate, and for which the customers have very little control (the typical EULA is similar to the Godfather's offer you cannot refuse), it should be different in the open systems source code sector. Has anyone written a script that converts "old" into CIFS? CIFS is not the server. CIFS is the protocol. If the setups of the server has changed, that's the server or the server configuration. You'll need to negotiate that with the server admins.
Re: mount -t cifs ... -o username=... file_mode=0777 ignored
On Tue, Aug 17, 2021 at 11:21 AM Yasha Karant wrote: > > This is a poor design decision on the part of the Linux systems > implementers, as it breaks backward compatibility. There is no reason > that an "auto-translator" from CIFS to what has been used in > unix/BSD/linux for a very long time should not have been implemented. Please do not say why work should have been done that you haven't tried to do yourself. CIFS, for example, supports multiple layers of both username and group based permissions, with more complex inheritance, ordered layers of "permit" and "deny" for each user or group, and considerable awkwardness resolving them that costs development, time, resources, and can cost a lot of tearing out of hair when trying to transform it to POSIX style permissions. CIFS was not designed for UNIX. It was designed for Windows file-sharing, which has quite a few different distinctions due to the previous VFAT or more modern NTFS filesystems which underly windows filesystems and their capabilities. NFSv4 ACL's come close to these permissions, but managing those in the Linux world is a serious pain in the ass. Samba does a pretty good of transforming underlying POSIX filesystems into CIFS compatible access, > Although this practice is not uncommon in the profiteer sector as > planned obsolescence for cash flow and other fiscal measures dominate, > and for which the customers have very little control (the typical EULA > is similar to the Godfather's offer you cannot refuse), it should be > different in the open systems source code sector. Has anyone written a > script that converts "old" into CIFS? CIFS is not the server. CIFS is the protocol. If the setups of the server has changed, that's the server or the server configuration. You'll need to negotiate that with the server admins.
AW: Re: mount -t cifs ... -o username=... file_mode=0777 ignored
Why not adapt the original permits to 0777 ? Seems more consistent and may be the real cause. Regards, Rainer Headline on the library: "Attention, Reading endangers ignorance" . Let me add: Pictograms are safe Gesendet mit der Telekom Mail App <https://urldefense.proofpoint.com/v2/url?u=https-3A__kommunikationsdienste.t-2Donline.de_redirects_email-5Fapp-5Fandroid-5Fsendmail-5Ffooter=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=CL6Z3TldMlxZEouaT48S05EEInB1kPxQQefe-1gyVEg=n96POQnp8Sf2I9JqPTkdrWoubDP7XJmjq7eITkQJLZc= > --- Original-Nachricht --- Von: R.Laatsch Betreff: AW: Re: mount -t cifs ... -o username=... file_mode=0777 ignored Datum: 18. August 2021, 2:06 An: Ekkard Gerlach Cc: scientific-linux-users@fnal.gov Try sshfs, please. My best advice. Regards, Rainer Gesendet mit der Telekom Mail App <https://urldefense.proofpoint.com/v2/url?u=https-3A__kommunikationsdienste.t-2Donline.de_redirects_email-5Fapp-5Fandroid-5Fsendmail-5Ffooter=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=0b7Db4zzTl3eWwkldIgV1C1qxgRnkaF4JJLRM_XYzDM=GdbupBNbCvT0jov11EZoS3qxv56nLyGFG9rUOdJm8d8=> --- Original-Nachricht --- Von: Ekkard Gerlach Betreff: Re: mount -t cifs ... -o username=... file_mode=0777 ignored Datum: 17. August 2021, 20:19 An: SCIENTIFIC-LINUX-USERS@fnal.gov Am 17.08.21 um 15:14 schrieb Mark Stodola: > On 8/17/21 7:38 AM, Ekkard Gerlach wrote: >> Hi, >> >> options gid=users,file_mode=0777,dir_mode=0777 are ignored in SL 6.10: >> >> root@arthur <mailto:root@arthur> :/home/pc41# /bin/mount -t cifs // 10.0.0.41/public <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.41_public=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=0b7Db4zzTl3eWwkldIgV1C1qxgRnkaF4JJLRM_XYzDM=yx06dGejaE7TzgATsVyK5TznC9tBpogGUZg46s51-Qs=> >> /home/pc41/usb-stick -o >> username=xxx,password=xxx,gid=users,file_mode=0777,dir_mode=0777 >> root@arthur <mailto:root@arthur> :/home/pc41# ls usb-stick/ -l >> insgesamt 0 >> drwxr-xr-x 3 root users 0 17. Aug 13:39 DCIM >> >> You see: "root users" and users can't write, mode 777 is ignored. >> With old Suse-server worked for 5 years. >> >> tia >> >> Ekkard > > gid, file_mode, dir_mode are all "fallback" values if they are not > provided by the CIFS server. So if your server has the CIFS unix > extensions, those permissions are honored and the *_mode options are > not applied. CIFS-Server makes same permissions: [public] path = /media/usb0 public = yes writable = yes comment = smb share printable = no #force user = root guest ok = yes read only = no #guest only = yes create mask = 0666 directory mask = 0777 with or without force user=root, =pc41, ... always the same. The medium is a vfat microSD card of a DCIM camera. > > If you haven't, I would read the man page mount.cifs(8 <https://urldefense.proofpoint.com/v2/url?u=http-3A__mount.cifs-288=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=0b7Db4zzTl3eWwkldIgV1C1qxgRnkaF4JJLRM_XYzDM=QMe0WZF-9NsUBNFOD7YXjuz5VLWBUEFXsO-YZ-L6oiA=> ) and the > section "File and directory ownership and permissions." > before I read cryptic manpages and try to understand I change to windows completely. Maybe SL software is even buggy, then I've lost much time. tia Ekkard > --
AW: Re: mount -t cifs ... -o username=... file_mode=0777 ignored
Try sshfs, please. My best advice. Regards, Rainer Gesendet mit der Telekom Mail App <https://urldefense.proofpoint.com/v2/url?u=https-3A__kommunikationsdienste.t-2Donline.de_redirects_email-5Fapp-5Fandroid-5Fsendmail-5Ffooter=DwIFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=0b7Db4zzTl3eWwkldIgV1C1qxgRnkaF4JJLRM_XYzDM=GdbupBNbCvT0jov11EZoS3qxv56nLyGFG9rUOdJm8d8= > --- Original-Nachricht --- Von: Ekkard Gerlach Betreff: Re: mount -t cifs ... -o username=... file_mode=0777 ignored Datum: 17. August 2021, 20:19 An: SCIENTIFIC-LINUX-USERS@fnal.gov Am 17.08.21 um 15:14 schrieb Mark Stodola: > On 8/17/21 7:38 AM, Ekkard Gerlach wrote: >> Hi, >> >> options gid=users,file_mode=0777,dir_mode=0777 are ignored in SL 6.10: >> >> root@arthur <mailto:root@arthur> :/home/pc41# /bin/mount -t cifs // <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.41_public=DwIFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=0b7Db4zzTl3eWwkldIgV1C1qxgRnkaF4JJLRM_XYzDM=yx06dGejaE7TzgATsVyK5TznC9tBpogGUZg46s51-Qs= > >> /home/pc41/usb-stick -o >> username=xxx,password=xxx,gid=users,file_mode=0777,dir_mode=0777 >> root@arthur <mailto:root@arthur> :/home/pc41# ls usb-stick/ -l >> insgesamt 0 >> drwxr-xr-x 3 root users 0 17. Aug 13:39 DCIM >> >> You see: "root users" and users can't write, mode 777 is ignored. >> With old Suse-server worked for 5 years. >> >> tia >> >> Ekkard > > gid, file_mode, dir_mode are all "fallback" values if they are not > provided by the CIFS server. So if your server has the CIFS unix > extensions, those permissions are honored and the *_mode options are > not applied. CIFS-Server makes same permissions: [public] path = /media/usb0 public = yes writable = yes comment = smb share printable = no #force user = root guest ok = yes read only = no #guest only = yes create mask = 0666 directory mask = 0777 with or without force user=root, =pc41, ... always the same. The medium is a vfat microSD card of a DCIM camera. > > If you haven't, I would read the man > page<https://urldefense.proofpoint.com/v2/url?u=http-3A__mount.cifs-288=DwIFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=0b7Db4zzTl3eWwkldIgV1C1qxgRnkaF4JJLRM_XYzDM=QMe0WZF-9NsUBNFOD7YXjuz5VLWBUEFXsO-YZ-L6oiA= > > ) and the > section "File and directory ownership and permissions." > before I read cryptic manpages and try to understand I change to windows completely. Maybe SL software is even buggy, then I've lost much time. tia Ekkard > --
Re: mount -t cifs ... -o username=... file_mode=0777 ignored
Am 17.08.21 um 15:14 schrieb Mark Stodola: On 8/17/21 7:38 AM, Ekkard Gerlach wrote: Hi, options gid=users,file_mode=0777,dir_mode=0777 are ignored in SL 6.10: root@arthur:/home/pc41# /bin/mount -t cifs //10.0.0.41/public /home/pc41/usb-stick -o username=xxx,password=xxx,gid=users,file_mode=0777,dir_mode=0777 root@arthur:/home/pc41# ls usb-stick/ -l insgesamt 0 drwxr-xr-x 3 root users 0 17. Aug 13:39 DCIM You see: "root users" and users can't write, mode 777 is ignored. With old Suse-server worked for 5 years. tia Ekkard gid, file_mode, dir_mode are all "fallback" values if they are not provided by the CIFS server. So if your server has the CIFS unix extensions, those permissions are honored and the *_mode options are not applied. CIFS-Server makes same permissions: [public] path = /media/usb0 public = yes writable = yes comment = smb share printable = no #force user = root guest ok = yes read only = no #guest only = yes create mask = 0666 directory mask = 0777 with or without force user=root, =pc41, ... always the same. The medium is a vfat microSD card of a DCIM camera. If you haven't, I would read the man page mount.cifs(8) and the section "File and directory ownership and permissions." before I read cryptic manpages and try to understand I change to windows completely. Maybe SL software is even buggy, then I've lost much time. tia Ekkard --
Re: mount -t cifs ... -o username=... file_mode=0777 ignored
This is a poor design decision on the part of the Linux systems implementers, as it breaks backward compatibility. There is no reason that an "auto-translator" from CIFS to what has been used in unix/BSD/linux for a very long time should not have been implemented. Although this practice is not uncommon in the profiteer sector as planned obsolescence for cash flow and other fiscal measures dominate, and for which the customers have very little control (the typical EULA is similar to the Godfather's offer you cannot refuse), it should be different in the open systems source code sector. Has anyone written a script that converts "old" into CIFS? Yasha Karant On 8/17/21 6:14 AM, Mark Stodola wrote: On 8/17/21 7:38 AM, Ekkard Gerlach wrote: Hi, options gid=users,file_mode=0777,dir_mode=0777 are ignored in SL 6.10: root@arthur:/home/pc41# /bin/mount -t cifs //10.0.0.41/public /home/pc41/usb-stick -o username=xxx,password=xxx,gid=users,file_mode=0777,dir_mode=0777 root@arthur:/home/pc41# ls usb-stick/ -l insgesamt 0 drwxr-xr-x 3 root users 0 17. Aug 13:39 DCIM You see: "root users" and users can't write, mode 777 is ignored. With old Suse-server worked for 5 years. tia Ekkard gid, file_mode, dir_mode are all "fallback" values if they are not provided by the CIFS server. So if your server has the CIFS unix extensions, those permissions are honored and the *_mode options are not applied. If you haven't, I would read the man page mount.cifs(8) and the section "File and directory ownership and permissions." I hope that helps. -Mark
Re: mount -t cifs ... -o username=... file_mode=0777 ignored
On 8/17/21 7:38 AM, Ekkard Gerlach wrote: Hi, options gid=users,file_mode=0777,dir_mode=0777 are ignored in SL 6.10: root@arthur:/home/pc41# /bin/mount -t cifs //10.0.0.41/public /home/pc41/usb-stick -o username=xxx,password=xxx,gid=users,file_mode=0777,dir_mode=0777 root@arthur:/home/pc41# ls usb-stick/ -l insgesamt 0 drwxr-xr-x 3 root users 0 17. Aug 13:39 DCIM You see: "root users" and users can't write, mode 777 is ignored. With old Suse-server worked for 5 years. tia Ekkard gid, file_mode, dir_mode are all "fallback" values if they are not provided by the CIFS server. So if your server has the CIFS unix extensions, those permissions are honored and the *_mode options are not applied. If you haven't, I would read the man page mount.cifs(8) and the section "File and directory ownership and permissions." I hope that helps. -Mark
