git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Aw: Re: linux git init/clone on Netapp NTFS security style volumes

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jul 8, 2024, 21:46 UTC
Message-ID
<ZoxeQgi3RWIHUPya@tapette.crustytoothpaste.net>
In-Reply-To
<trinity-3d633a4a-10c6-444e-9e5c-79330941ddb6-1720457458565@3c-app-webde-bap34>
On 2024-07-08 at 16:50:58, github@online.ms wrote:
> The feature is very specific to Netapp. The (Netapp) volume is mounted using NFSv4, but chmod operations are not allowed as permissions have to be managed using Windows.
> Currently, OS is ubuntu 22.04. I'm confident that the distribution does not make a difference.

Okay, then I think the answer is that your NFS server is considered to be broken, and there are a variety of NFS breakages that violate POSIX that we don't work around, including the very common one where open(file, O_RDWR, 0444) doesn't work.

I will tell you that this configuration will break a lot of other tools, not just Git. Git LFS and its testsuite will be broken; the Perl, Python, and Ruby testsuites will also be broken; and there's various other software I know of that simply will not work on such a file system (and a simple search turns up yet more). chmod is a really fundamental piece of Unix functionality, and even if you patch this in Git, you're going to see a bunch of breakage and most upstreams and distros won't care.

Show 10 quoted lines
> Following section of the code should be skipped for given case.
> https://github.com/git/git/blob/master/config.c#L3434-L3438
> 
> 		if (chmod(get_lock_file_path(&lock), st.st_mode & 07777) < 0) {
> 			error_errno(_("chmod on %s failed"), get_lock_file_path(&lock));
> 			ret = CONFIG_NO_WRITE;
> 			goto out_free;
> 		}
> 
> I'm looking for some advice how to best skip or catch this section.

We have core.filemode, but according to the documentation, that only takes into consideration the executable bit. So I suppose you could add a third option, "none" (or "broken"), that is the equivalent of false but also means that chmod is broken altogether and shouldn't be used. The documentation would need to be updated as well.

Someone else might prefer a different option for this altogether, but you may not get that feedback until you send a patch.

> In addition, I came across this Netapp setting which might just ignore the chmod operations without Client side failure. I haven't tested it yet.
> https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/Can_I_set_UNIX_style_permissions_from_an_NFS_mount_on_an_NTFS_qtree

That might be also be a viable approach. I don't see an option to disable this functionality in the Linux NFS client, which is where I would have looked.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
Previous: github@online.ms
Message 4 of 4 in “linux git init/clone on Netapp NTFS security style volumes”
  1. github@online.msJul 6, 2024
  2. brian m. carlsonJul 7, 2024
  3. Aw: Re: linux git init/clone on Netapp NTFS security style volumesgithub@online.ms, Jul 8, 2024
  4. brian m. carlsonJul 8, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.