Re: umask - default user settings?

On 18/07/2024 00:01, Greg Wooledge wrote: On Wed, Jul 17, 2024 at 17:58:57 +0100, Tim Woodall wrote: No, I'm talking about sudo, not su. I'm not a sudo user so I can't test but my understanding is that root inherits the umask of the invoking user (or it used to) Looks like this is still true

Re: umask - default user settings?

On 19/07/2024 10:45, songbird wrote: - Does MATE use scopes and services to run applications an components? "ps xwf" and "systemd-cgls" trees may clarify where started applications appear. neither of those show all the programs that i have included on the panels, but there are cgroups and

Re: umask - default user settings?

> I've added a bit of content to > > <https://wiki.debian.org/EnvironmentVariables>. > > Isn't the following a more suitable article for umask? > <https://wiki.debian.org/Permissions#Setting_default_umask> > I think, it is better to drop UMask note from EnvironmentVariables. I've made some minor changes to both pages.

Re: umask - default user settings?

. If other people want to try to drum up interest in environment configuration, then there'll be documentation available for end users to follow. I've added a bit of content to <https://wiki.debian.org/EnvironmentVariables>. Isn't the following a more suitable article for umask?

Re: umask - default user settings?

Max Nikulin wrote: > On 19/07/2024 04:11, songbird wrote: >>so far, agreed, i poked at it a bit the other day to see >> if MATE would work with the roughly (user-@1000,etc) systemd >> unit approach but that didn't accomplish anything i could tell. > > It would be great if those, who tried it,

Re: umask - default user settings?

On 19/07/2024 04:11, songbird wrote: so far, agreed, i poked at it a bit the other day to see if MATE would work with the roughly (user-@1000,etc) systemd unit approach but that didn't accomplish anything i could tell. It would be great if those, who tried it, reported more precise what

Re: umask - default user settings?

Greg Wooledge wrote: ... > It only becomes *hard* when Desktop Environments are introduced into the > picture. so far, agreed, i poked at it a bit the other day to see if MATE would work with the roughly (user-@1000,etc) systemd unit approach but that didn't accomplish anything i could tell.

Re: umask - default user settings?

On Thu, Jul 18, 2024 at 09:07:48 +0700, Max Nikulin wrote: > Taking into account a number of bugs, perhaps it is not really bad that > recipes how to change umask are not easily available. Documentation should > be extensive enough to describe possible pitfalls. That's an odd stance, e

Re: umask - default user settings?

that recipes how to change umask are not easily available. Documentation should be extensive enough to describe possible pitfalls.

Re: umask - default user settings?

On Wed, Jul 17, 2024 at 20:51:40 +0200, Franco Martelli wrote: > If you plan to add your contribute to the wiki page (see above) in the > section: "Desktop Environments and systemd user services" e.g.: > > - ... > - systemctl --user daemon-reload > - /Restart your Desktop session/ > > Please

Re: umask - default user settings?

On 16/07/24 at 15:46, Greg Wooledge wrote: I've added a bit of content to . On 17/07/24 at 04:37, Max Nikulin wrote: daemon-reload is not enough in KDE. krunner and plasmashell services have been started already, so changes would not apply

Re: umask - default user settings?

On Wed, Jul 17, 2024 at 17:58:57 +0100, Tim Woodall wrote: > No, I'm talking about sudo, not su. I'm not a sudo user so I can't test > but my understanding is that root inherits the umask of the invoking > user (or it used to) Looks like this is still true. hobbit:~$ bash hobbit:~$

Re: umask - default user settings?

On Wed, 17 Jul 2024, Max Nikulin wrote: On 17/07/2024 15:37, Tim Woodall wrote: umask 077 can come with its own problems when using shared directories. <https://wiki.debian.org/UserPrivateGroups> Taking into account old 022 vs. 002 discussions it might be 007. I'm not a sudo user bu

Re: umask - default user settings?

On 15/07/2024 09:15, Alan D. Salewski wrote: I suspect that most people /do/ change it, once they become aware of it, for the very reason stated in the comment above 'UMASK' in the /etc/login.defs file:     # UMASK is the default umask value for pam_umask and is used by     # useradd

Re: umask - default user settings?

On Wed, Jul 17, 2024 at 22:10:28 +0700, Max Nikulin wrote: > Do you mean the following bug or something else? > <https://bugs.debian.org/711104> > login: su - doesn't set umask > Fixed in version pam/1.5.3-1 > Tue, 16 Jan 2024 00:19:23 + Huh... given the age o

Re: umask - default user settings?

On 17/07/2024 15:37, Tim Woodall wrote: umask 077 can come with its own problems when using shared directories. <https://wiki.debian.org/UserPrivateGroups> Taking into account old 022 vs. 002 discussions it might be 007. I'm not a sudo user but IIUC, root inherits the umask, whi

Re: umask - default user settings?

On Mon, 15 Jul 2024, Jeffrey Walton wrote: Debian is a multi-user operating system. Decisions should be made accordingly. I suppose umask is a moot point on phones and tablets, where single-user is often the use case. umask 077 can come with its own problems when using shared directories

Re: umask - default user settings?

On 16/07/2024 10:39, Greg Wooledge wrote: hobbit:~$ cat .config/systemd/user/service.d/env.conf [Service] Environment="FOO=%h/test123" "BAR=b a r" hobbit:~$ systemctl --user daemon-reload hobbit:~$ systemctl --user start xterm.service daemon-reload is not enough in KDE. krunner and plasmashell

Re: umask - default user settings?

On Jul 16, 2024, Thomas Schmitt wrote: > Hi, > > to...@tuxteam.de wrote: > > Somehow I'm glad I stayed away from DEs and systemd up to now. Perhaps I > > just retire before the alternatives aren't viable anymore. Or perhaps, as > > with PulseAudio, I can leapfrog that "tech". > > Retirement is

Re: umask - default user settings?

Darac Marjal wrote: > I'm not saying that what you did was wrong, but systemd provides a > few shortcuts which can make things a bit more user-friendly. > > On 16/07/2024 04:39, Greg Wooledge wrote: > > OK. Let's follow this path a bit. > > I googled "how to create a systemd user service" and

Re: umask - default user settings?

Debian is a multi-user operating system. Decisions should be made accordingly. I suppose umask is a moot point on phones and tablets, where single-user is often the use case. On the contrary, modern Android is strongly multi-user. Each "app" tends to be allocated its own user ID.

Re: umask - default user settings?

I'm not saying that what you did was wrong, but systemd provides a few shortcuts which can make things a bit more user-friendly. On 16/07/2024 04:39, Greg Wooledge wrote: OK. Let's follow this path a bit. I googled "how to create a systemd user service" and got

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 1:45 PM wrote: >[...] > > (The most probable outcome though is even less rosy: everything'll run in > the browser, and Secure Boot will make sure that your hardware refuses to > run anything else, because the chips are sponsored by the Ad Industry. Lol...

Re: umask - default user settings?

Hi, to...@tuxteam.de wrote: > Somehow I'm glad I stayed away from DEs and systemd up to now. Perhaps I > just retire before the alternatives aren't viable anymore. Or perhaps, as > with PulseAudio, I can leapfrog that "tech". Retirement is no solution. What shall we retirees do when X11 is laid

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 11:52:29AM -0400, Greg Wooledge wrote: > On Tue, Jul 16, 2024 at 22:21:23 +0700, Max Nikulin wrote: > > Greg, do you have an example when Environment= in service.d works, but an > > environment.d file does not? > > Oh gods, there's MORE shit to worry about?? Of course

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 22:21:23 +0700, Max Nikulin wrote: > Greg, do you have an example when Environment= in service.d works, but an > environment.d file does not? Oh gods, there's MORE shit to worry about?? Of course there is. Bloody hell. In previous years, I remember exploring

Re: umask - default user settings?

P.S. There is <https://wiki.debian.org/Debate/umask> from 2013 briefly discussing 022 vs. 002 values.

Re: umask - default user settings?

On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote: > Now we just need for GNOME users to discover a way to configure the > programs that are started as children of dbus, and then we can move > forward. Documentation would be my top priority. If other people want > to try to drum up

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 18:42:40 +0700, Max Nikulin wrote: > On 16/07/2024 10:39, Greg Wooledge wrote: > > hobbit:~/.config$ cat systemd/user/xterm.service > > I am a bit afraid that corner cases might exist because there are no > .service files for applications started from menus and runners

Re: umask - default user settings?

On 16/07/2024 10:39, Greg Wooledge wrote: On Tue, Jul 16, 2024 at 09:58:20 +0700, Max Nikulin wrote: cat ~/.config/systemd/user/service.d/umask.conf [Service] UMask=0007 I googled "how to create a systemd user service" and got The following blog posts (0pointer.de) may be a bi

Re: umask - default user settings?

Greg Wooledge (12024-07-15): > Neither am I. But more to the point, it appears that the default umask > literally *cannot* be changed in any kind of universal way. There are, > like, half a dozen different places you'd have to apply a change in > order to cover just the *most commo

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 09:58:20 +0700, Max Nikulin wrote: > I have naively tried > > cat ~/.config/systemd/user/service.d/umask.conf > [Service] > UMask=0007 > > From xterm and konsole: > > umask > 0007 OK. Let's follow this path a bit. I googled "h

Re: umask - default user settings?

On 16/07/2024 08:34, Greg Wooledge wrote: On Tue, Jul 16, 2024 at 08:02:45 +0700, Max Nikulin wrote: systemd.exec(5) UMask= [...] [5] refers to <https://systemd.io/USER_RECORD>. I do not have systemd-homed running (minimal KDE). I have no idea concerning default Gnome installati

Re: umask - default user settings?

On Mon, Jul 15, 2024 at 9:34 PM Greg Wooledge wrote: > > On Tue, Jul 16, 2024 at 08:02:45 +0700, Max Nikulin wrote: > [...] > > systemd.exec(5) > > > > > UMask= > > > Controls the file mode creation mask. Takes an access mode in octal > > > nota

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 08:02:45 +0700, Max Nikulin wrote: > (I am not convinced that default umask should be changed) Neither am I. But more to the point, it appears that the default umask literally *cannot* be changed in any kind of universal way. There are, like, half a dozen differ

Re: umask - default user settings?

On 15/07/2024 20:03, Greg Wooledge wrote: If you use a Desktop Environment, go to your DE's support mailing list, and ask them how to set your umask so that it works as expected in all of your programs. (I am not convinced that default umask should be changed) systemd.exec(5) UMask

Re: umask - default user settings?

to read or to ignore ~/.profile and ~/.xsessionrc. SDDM reads them. However it affects only /usr/bin/startplasma-x11 subtree. Most user applications are started under "/lib/systemd/systemd --user" https://wiki.archlinux.org/title/umask#Set_umask_value_for_KDE_/_Plasma Setting the umask

Re: umask - default user settings?

ast one is not clear for me. Why should I allow the rest of the world > > read my personal documents? These are private and no one else should be able > > to read them! > > > > So I would have expected a setting of "rw- r-- ---" for any files. > > > > Before

Re: umask - default user settings?

On 14/07/24 at 20:44, to...@tuxteam.de wrote: so they aren't children of the GNOME top-level process, and don't inherit the umask or environment from the session. I'm totally willing to believe that KDE is different, but it's not clear whether "Lists" has tried this

Re: umask - default user settings?

them how to set your umask so that it works as expected in all of your programs. This must include programs that are launched at login, and programs that are launched by a menu or icon, and terminal emulators (and not merely the shells that run inside terminal emulators). Make sure whatever

Re: umask - default user settings?

On 2024-07-15 14:30, Eduardo M KALINOWSKI wrote: I'm not sure if the Debian default should be changed, though. One thing to consider is that in modern software development practices the idea of secure/private by default is getting more and more important and implemented. It is good practice

Re: umask - default user settings?

" for any files. Before someone argues, "you can change this by editing umask", yes, I know of this of course. But it is not clear for me, why it is set that way by default and not as I would have expected as described above. Sure, there is a reason for this, so I will be happy, if s

Re: umask - default user settings?

On Mon, Jul 15, 2024 at 09:04:54 +0200, Hans wrote: > Also, when some other applicatiions are setting correct rights. > Some do, some don't. File bug reports against the ones which don't.

Re: umask - default user settings?

The point us, that debian is creating a default user "for your daily work" at installation with umask 022. And we are not talking about experienced users, but of linux beginners. I doubt, they are aware of umask and rights and so. Debian is made for every people, not only for experien

Re: umask - default user settings?

Here is some cool ascii art to illustrate permissions after mount. The (x)_b notation indicates that x is in base b. # permissions # rwxr-xr-x dirs local dmask=022 # (22)_8 = (10010)_2 local fmask=133 # (133)_8 = ( 1011011)_2

Re: umask - default user settings?

On 2024-07-14 22:15:34, "Alan D. Salewski" spake thus: [...] The user's umask value would matter less if the default perms of user $HOME directories were 077 s/were/were from a umask of/

Re: umask - default user settings?

On Sun, Jul 14, 2024 at 22:15:34 -0400, Alan D. Salewski wrote: > As it is, it > looks[1] like default perms for $HOME are 0755. If home directories are created with adduser, then the contents of /etc/adduser.conf are relevant: # The permissions mode for home directories of non-system users. #

Re: umask - default user settings?

in the comment above 'UMASK' in the /etc/login.defs file: # UMASK is the default umask value for pam_umask and is used by # useradd and newusers to set the mode of the new home directories. # 022 is the "historical" value in Debian for UMASK # 027, or even 077, could be

Re: umask - default user settings?

On 15/07/2024 01:32, Hans wrote: I see itthe other way round. No, if you are in the secure area, it is the responsibility of the owner to make it secure by design i.e with dself closing doors where you can not look into or windows with curtains. The door is closed by default in bookworm. User

Re: umask - default user settings?

On Sun, Jul 14, 2024 at 08:31:23PM +0200, Me wrote: > On 2024-07-14 19:57, to...@tuxteam.de wrote: [...] > > [1] https://wiki.debian.org/Xsession > > Did you actually try this? I did and it did not what I was expecting it to > do. But maybe I should try again, maybe things have improved in the

Re: umask - default user settings?

foo() function to work." Or "Hey friends, I've made some changes to my bar.c file that you might want to look at." And then they can just read the files directly from your home directory. If you don't like this setting, change it. Setting umask in your shell profile isn'

Re: umask - default user settings?

On 2024-07-14 19:43, Me wrote: Setting umask in your shell profile isn't that hard indeed. I've doing that for years. However, that does not mean your DE will honour that setting. I have tried to do so for KDE (more specifically Krusader), but I ended up nowhere. I haven't found a setting

Re: umask - default user settings?

ss, and don't inherit the umask or environment from the session. > > I'm totally willing to believe that KDE is different, but it's not > clear whether "Lists" has tried this and failed, or simply didn't know > that it should be done this way. > > It would be excellent to r

Re: umask - default user settings?

at you might want to look at." And then they can just read the files directly from your home directory. If you don't like this setting, change it. Setting umask in your shell profile isn't that hard indeed. I've doing that for years. However, that does not mean your DE will honour that setting.

Re: umask - default user settings?

* 2024-07-14 19:44:35+0200, li...@nodatagrabbing.com wrote: > Setting umask in your shell profile isn't that hard indeed. I've doing > that for years. However, that does not mean your DE will honour that > setting. I have tried to do so for KDE (more specifically Krusader), but >

Re: umask - default user settings?

I see itthe other way round. No, if you are in the secure area, it is the responsibility of the owner to make it secure by design i.e with dself closing doors where you can not look into or windows with curtains. However, I presume, debian wants to be secure. If no one cares and all agree

Re: umask - default user settings?

On Sun, Jul 14, 2024 at 19:57:45 +0200, to...@tuxteam.de wrote: > On Sun, Jul 14, 2024 at 07:44:35PM +0200, Lists wrote: > > Setting umask in your shell profile isn't that hard indeed. I've doing that > > for years. However, that does not mean your DE will honour that setting. &g

Re: umask - default user settings?

Hans (12024-07-14): > Greg, I do not agree. If I am writing a document with private content, then I If you are writing something confidential, it is your responsibility to lock the door of your office. Regards, -- Nicolas George

Re: umask - default user settings?

Greg, I do not agree. If I am writing a document with private content, then I do not want to let it be read by someone else except me. No one has to read any letters or cv's or maybe documents for my lawyer, my medic, my friends or whatever. And after years there are a lot of documents one

Re: umask - default user settings?

Hi, Hans wrote: > I am wondering, why on a multiuser system like debian the rights for a > normal user are "rw- r-- r--", (owner: user and ownergroup: usergroup) Because the usual umask of 0022 keeps the more credulous programs from giving w-permission to everybody. Any program

Re: umask - default user settings?

;Hey Betty, > > can you take a look at my .bashrc? I can't get my foo() function to > > work." Or "Hey friends, I've made some changes to my bar.c file that > > you might want to look at." And then they can just read the files > > directly from your home dire

Re: umask - default user settings?

On Sun, Jul 14, 2024 at 19:44:35 +0200, Lists wrote: > Setting umask in your shell profile isn't that hard indeed. I've doing that > for years. However, that does not mean your DE will honour that setting. I > have tried to do so for KDE (more specifically Krusader), but I ended up >

Re: umask - default user settings?

On Sun, Jul 14, 2024 at 19:38:26 +0200, Hans wrote: > Hi Greg, > > yes, did already change it. However, this looks like a security hole for me, > as I believe, not many people or admins are changing this. > > IMO debian should change this in the next release, but I doubt it. > > I will ask the

Re: umask - default user settings?

at you might want to look at." And then they can just read the files directly from your home directory. If you don't like this setting, change it. Setting umask in your shell profile isn't that hard indeed. I've doing that for years. However, that does not mean your DE will honour that setting.

Re: umask - default user settings?

Hi Greg, yes, did already change it. However, this looks like a security hole for me, as I believe, not many people or admins are changing this. IMO debian should change this in the next release, but I doubt it. I will ask the security team for it, they will decide. Have fun! Hans Am

Re: umask - default user settings?

On Sun, Jul 14, 2024 at 19:09:54 +0200, Hans wrote: > I am wondering, why on a multiuser system like debian the rights for a normal > user are "rw- r-- r--", (owner: user and ownergroup: usergroup) Tradition, and a culture based around sharing. The Unix culture of openness and freedom

umask - default user settings?

efore someone argues, "you can change this by editing umask", yes, I know of this of course. But it is not clear for me, why it is set that way by default and not as I would have expected as described above. Sure, there is a reason for this, so I will be happy, if someone could enlighten me. Best Hans

Re: VFAT vs. umask.

On Thu 04 Aug 2022 at 13:27:34 (-0400), gene heskett wrote: > On 8/4/22 10:47, pe...@easthope.ca wrote: > > From: Charles Curley > > Date: Sat, 30 Jul 2022 13:39:00 -0600 > > > The preparation of any storage medium requires at least two steps. To > > > format means ... > > > > > > In

Re: VFAT vs. umask.

On Wed 03 Aug 2022 at 08:37:24 (-0700), pe...@easthope.ca wrote: > From: David Wright > Date: Sun, 31 Jul 2022 14:15:26 -0500 > > So "primary store" probably means Master Copy of Your Data. > > https://en.wiktionary.org/wiki/primary#Adjective sense 2. >

Re: VFAT vs. umask.

On 8/4/22 10:47, pe...@easthope.ca wrote: From: Charles Curley Date: Sat, 30 Jul 2022 13:39:00 -0600 The preparation of any storage medium requires at least two steps. To format means ... In another step one lays down a file system: ... Understood, at a superficial level at least.

Re: VFAT vs. umask.

From: Charles Curley Date: Sat, 30 Jul 2022 13:39:00 -0600 > The preparation of any storage medium requires at least two steps. To > format means ... > > In another step one lays down a file system: ... Understood, at a superficial level at least. Haven't invented or implemented a

Re: VFAT vs. umask.

> ... reformat the card to an ext format and you can forget about that. According to several other messages alignment and block size are concerns in reformatting. > So "primary store" probably means Master Copy of Your Data. https://en.wiktionary.org/wiki/primary#Adjective sense 2.

Re: VFAT vs. umask.

In previous copies of this message I omitted attribution of the quotes. From: David Wright Date: Sun, 31 Jul 2022 14:15:26 -0500 > ... reformat the card to an ext format and you can forget about that. According to several other messages alignment and block size are concerns in

Re: VFAT vs. umask.

> ... reformat the card to an ext format and you can forget about that. According to several other messages, alignment and block size are concerns. > So "primary store" probably means Master Copy of Your Data. https://en.wiktionary.org/wiki/primary#Adjective sense 2.

Re: VFAT vs. umask.

From: Date: Wed, 3 Aug 2022 06:58:27 +0200 > AFAIU, the only critical parameter for a partitioner is the alignment, > anyway. > ... > AFAIK there is no "protocol" for the media to tell your OS about its > preferred block size, and (USB/MMC) flash storage cheats anyway (the > reality is

Re: VFAT vs. umask.

On Tue, Aug 02, 2022 at 05:07:06PM -0700, pe...@easthope.ca wrote: [...] > 8 x 10^9 bytes / 1.6 x 10^7 sectors > ~= 8/16 x 10^3 bytes/sector > ~= 512 bytes/sector. > A familiar old number. > > Gparted also shows 4.00 MiB unallocated bytes at the front of the > device. This is gparted's

Re: VFAT vs. umask.

From: The Wanderer Date: Sun, 31 Jul 2022 12:29:54 -0400 > The filesystem that's on the device when it's shipped from the factory > is almost certainly already configured in this way. My understanding is > that that is usually what is meant by saying that the "factory format" > of a flash

Re: VFAT vs. umask.

On Sun 31 Jul 2022 at 07:51:22 (-0700), pe...@easthope.ca wrote: > From: Linux-Fan > Date: Sat, 30 Jul 2022 21:37:37 +0200 > > Formatting it to ext2 should work and not cause any issues ... > > Other authorities claim "factory format" is optimal and wear of flash > storage is a concern. A

Re: VFAT vs. umask.

On Sun, Jul 31, 2022 at 12:29:54PM -0400, The Wanderer wrote: > On 2022-07-31 at 10:51, pe...@easthope.ca wrote: > > > From: Linux-Fan > > Date: Sat, 30 Jul 2022 21:37:37 +0200 > > >> Formatting it to ext2 should work and not cause any issues ... > > > > Other authorities claim

Re: VFAT vs. umask.

On 2022-07-31 at 10:51, pe...@easthope.ca wrote: > From: Linux-Fan > Date: Sat, 30 Jul 2022 21:37:37 +0200 >> Formatting it to ext2 should work and not cause any issues ... > > Other authorities claim "factory format" is optimal and wear of flash > storage is a concern. A revised

Re: VFAT vs. umask.

pe...@easthope.ca writes: From: Linux-Fan Date: Sat, 30 Jul 2022 21:37:37 +0200 > Formatting it to ext2 should work and not cause any issues ... Other authorities claim "factory format" is optimal and wear of flash storage is a concern. A revised "format" can impose worse conditions

Re: VFAT vs. umask.

From: Linux-Fan Date: Sat, 30 Jul 2022 21:37:37 +0200 > Formatting it to ext2 should work and not cause any issues ... Other authorities claim "factory format" is optimal and wear of flash storage is a concern. A revised "format" can impose worse conditions for wear? Does any

Re: VFAT vs. umask.

On Sat 30 Jul 2022 at 09:13:55 (-0700), pe...@easthope.ca wrote: > From: David Wright > Date: Fri, 29 Jul 2022 00:00:29 -0500 > > When you copy files that have varied permissions onto the FAT, you may > > get warnings about permissions that can't be honoured. (IIRC, copying > > ug=r,o= would not

Re: VFAT vs. umask.

On Sat, 2022-07-30 at 22:26 +0200, to...@tuxteam.de wrote: > > Rumour goes that the processor in the stick/card can cope better with > FAT. I don't know whether it's true, though. A long time ago I heard something along the lines that the first blocks in the storage device (where the the FAT

Re: VFAT vs. umask.

On Sat, Jul 30, 2022 at 09:37:37PM +0200, Linux-Fan wrote: > pe...@easthope.ca writes: > > > David, > > thanks for the reply. > > > > From: David Wright > > Date: Fri, 29 Jul 2022 00:00:29 -0500 > > > When you copy files that have varied permissions onto the FAT, you may > > > get

Re: VFAT vs. umask.

On Sat, 30 Jul 2022 09:13:55 -0700 pe...@easthope.ca wrote: > * In Linux, an ext file system avoids those complications. To my > knowledge, all SD cards are preformatted with a FAT. Therefore ext > requires reformatting. Not quite. The preparation of any storage medium requires at least two

Re: VFAT vs. umask.

pe...@easthope.ca writes: David, thanks for the reply. From: David Wright Date: Fri, 29 Jul 2022 00:00:29 -0500 > When you copy files that have varied permissions onto the FAT, you may > get warnings about permissions that can't be honoured. (IIRC, copying > ug=r,o= would not

Re: VFAT vs. umask.

David, thanks for the reply. From: David Wright Date: Fri, 29 Jul 2022 00:00:29 -0500 > When you copy files that have varied permissions onto the FAT, you may > get warnings about permissions that can't be honoured. (IIRC, copying > ug=r,o= would not complain, whereas u=r,go= would.)

Re: VFAT vs. umask.

From: Date: Fri, 29 Jul 2022 06:22:53 +0200 > No. A FAT file system has no permissions (and no user/group ownership). > All is faked one layer above. Understood. Aren't we saying the same thing in two ways. In natural language, 777 just means anyone can read & write & execute. 555

Re: VFAT vs. umask.

On Thu 28 Jul 2022 at 14:49:03 (-0700), pe...@easthope.ca wrote: > https://tldp.org/FAQ/Linux-FAQ/partitions.html has this example. > > $ mkdir /dos $ > mount -t msdos -o conv=text,umask=022,uid=100,gid=100 /dev/hda3 /dos > > Therefore a new file receives permiss

Re: VFAT vs. umask.

On Thu, Jul 28, 2022 at 02:49:03PM -0700, pe...@easthope.ca wrote: > https://tldp.org/FAQ/Linux-FAQ/partitions.html has this example. > > $ mkdir /dos $ > mount -t msdos -o conv=text,umask=022,uid=100,gid=100 /dev/hda3 /dos > > Therefore a new file receives permiss

VFAT vs. umask.

https://tldp.org/FAQ/Linux-FAQ/partitions.html has this example. $ mkdir /dos $ mount -t msdos -o conv=text,umask=022,uid=100,gid=100 /dev/hda3 /dos Therefore a new file receives permissions 755. Correct? But a FAT file has only all-user read-only permissions. Either 777 or 555. Correct

Re: Problème avec umask dans fstab sur un sous-dossier

tre mal l'usager 2 ou celui-ci a un umask différent. > J'ai vraiment du mal à comprendre...  > > > > Le 28/11/2021 à 21:10:05, didier gaumet a écrit : > > Le dimanche 28 novembre 2021 à 17:51 +0100, lists.deb...@netc.eu a > écrit : > > Merci de vos retou

Re: Problème avec umask dans fstab sur un sous-dossier

Je pense qu tu obtiendras des éléments de réponse en lisant les docs sur les sites, officiel de ntfs-3g, et persos de ses développeurs, ainsi que wikipedia et autres sources comparables Ce que je suppose c'est que NTFS étant un système de fichiers propriétaire dont les spécifications sont

Re: Problème avec umask dans fstab sur un sous-dossier

Merci du retour Didier, Je vais essayer de voir tout ça pendant la semaine. Entre-temps ce que je n'arrive pas trop à comprendre est-ce pourquoi 2 dossiers similaires (User1 et User2) finissent par avoir des permissions différentes, même si sous Windows ils ont exactement les mêmes paramètres

Re: Problème avec umask dans fstab sur un sous-dossier

Le dimanche 28 novembre 2021 à 17:51 +0100, lists.deb...@netc.eu a écrit : > Merci de vos retour :) >   > Je suis allé sur le site NTFS-3G site, j'ai lu toute la doc relative > au fichier usermap, mais j'ai eu deux soucis : >  - je n'ai pas réussi à trouver le fichier zip pour Windows Il (JP

Re: Problème avec umask dans fstab sur un sous-dossier

Merci de vos retour :) Je suis allé sur le site NTFS-3G site, j'ai lu toute la doc relative au fichier usermap, mais j'ai eu deux soucis : - je n'ai pas réussi à trouver le fichier zip pour Windows - une foi que j'ai essayé de lancer l'exécution sur Debian, je n'ai pas trop compris les

Re: Problème avec umask dans fstab sur un sous-dossier

à Marc: pour compléter l'intervention de Hugues, tu peux regarder la page man de ntfs-3g (par défaut quand tu montes du ntfs dans Debian, c'est ntfs-3g qui est a l'oeuvre) http://manpages.ubuntu.com/manpages/bionic/en/man8/mount.ntfs.8.html où il est suggéré de passer par une liste de

Re : Problème avec umask dans fstab sur un sous-dossier

ques, une SSD avec les 2 systèmes et un HDD où sont les > autres fichiers (documents, images, musique,...). > > Mon idée est de partager ce HDD entre Windows et Debian. Pour le faire, dans > mon fichier fstab, j'ai rajouté la ligne suivante : > > UUID=ACB23705B236D414   /mnt/wind

Problème avec umask dans fstab sur un sous-dossier

Debian. Pour le faire, dans mon fichier fstab, j'ai rajouté la ligne suivante : UUID=ACB23705B236D414 /mnt/windows ntfs-3g defaults,umask=000 0 0 Les dossiers présents montent correctement dans le dossier /mnt/windows : $ ls -l /mnt/windows/ total 80 drwxrwxrwx 1 root root 4096 14 nov. 20:20

  1   2   3   4   5   >