{"thread":{"id":"61745","subject":"linux git init/clone on Netapp NTFS security style volumes","startedAt":"2024-07-06T19:35:32Z","lastAt":"2024-07-08T21:46:51Z","messageCount":4,"participants":["github@online.ms","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"498174","messageId":"trinity-ea5945a3-0663-4e48-b995-913003b5e932-1720294530422@msvc-mesg-web002","threadId":"61745","inReplyTo":null,"subject":"linux git init/clone on Netapp NTFS security style volumes","fromName":"","fromEmail":"github@online.ms","sentAt":"2024-07-06T19:35:30Z","receivedAt":"2024-07-06T19:35:32Z","isPatch":false,"sender":{"key":"github@online.ms","avatar":null},"body":"Hello,\n \nI'm trying to execute git init and git clone operations on a linux client that mounts a Netapp volume with NTFS Security Style. Meaning the client is Linux based but the filesystem is managed from Windows side - especially linux chmod operations are not permitted.\n \nMaybe a new CLI option might be helpful to skip those chmod operations.\n \n \n$ git version\ngit version 2.34.1\n \n \nERROR git clone\n$ git clone https://github.com/git/git.git\nCloning into 'git'...\nerror: chmod on /mnt/git-clone-test/git/.git/config.lock failed: Operation not permitted\nfatal: could not set 'core.filemode' to 'false'\n \n$ git config --global --replace-all core.fileMode false\n \n$ git clone https://github.com/git/git.git\nCloning into 'git'...\nerror: chmod on /mnt/git-clone-test/git/.git/config.lock failed: Operation not permitted\nfatal: could not set 'core.filemode' to 'false'\n \n \nERROR git init\n$ git init\nhint: Using 'master' as the name for the initial branch. This default branch name\nhint: is subject to change. To configure the initial branch name to use in all\nhint: of your new repositories, which will suppress this warning, call:\nhint:\nhint:   git config --global init.defaultBranch <name>\nhint:\nhint: Names commonly chosen instead of 'master' are 'main', 'trunk' and\nhint: 'development'. The just-created branch can be renamed via this command:\nhint:\nhint:   git branch -m <name>\nerror: chmod on /mnt/git-init-test/.git/config.lock failed: Operation not permitted\nfatal: could not set 'core.filemode' to 'false'\n \n$ git config --global --replace-all core.fileMode false\n$ git init\nerror: chmod on /mnt/git-init-test/.git/config.lock failed: Operation not permitted\nfatal: could not set 'core.repositoryformatversion' to '0'\n \n$ cat .git/config\n[core]\n        repositoryformatversion = 0\n \n$ git status\nfatal: not a git repository (or any parent up to mount point /data/care)\nStopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).\n \n \nThanks&Best\n \nJH\n"},{"id":"498203","messageId":"ZoryWtGqsD9iIafI@tapette.crustytoothpaste.net","threadId":"61745","inReplyTo":"trinity-ea5945a3-0663-4e48-b995-913003b5e932-1720294530422@msvc-mesg-web002","subject":"Re: linux git init/clone on Netapp NTFS security style volumes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-07-07T19:54:02Z","receivedAt":"2024-07-07T19:54:06Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-07-06 at 19:35:30, github@online.ms wrote:\n> Hello,\n>  \n> I'm trying to execute git init and git clone operations on a linux\n> client that mounts a Netapp volume with NTFS Security Style. Meaning\n> the client is Linux based but the filesystem is managed from Windows\n> side - especially linux chmod operations are not permitted.\n>  \n> Maybe a new CLI option might be helpful to skip those chmod operations.\n\nI'm not surprised by this, because Windows volumes under WSL also have\nthe same problem.  However, I don't see the behaviour you describe when\ncreating a new file system with NTFS on Linux and using ntfs-3g to\nmount with default options.  In my case, everything works just fine.\n\nNote that I didn't try using the old non-FUSE driver because that's\ndeprecated and I don't believe it's available anymore in Debian sid.\n\nWhat OS (including version) are you using and how are you mounting the\nfile system?\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"498287","messageId":"trinity-3d633a4a-10c6-444e-9e5c-79330941ddb6-1720457458565@3c-app-webde-bap34","threadId":"61745","inReplyTo":"ZoryWtGqsD9iIafI@tapette.crustytoothpaste.net","subject":"Aw: Re: linux git init/clone on Netapp NTFS security style volumes","fromName":"","fromEmail":"github@online.ms","sentAt":"2024-07-08T16:50:58Z","receivedAt":"2024-07-08T16:51:09Z","isPatch":false,"sender":{"key":"github@online.ms","avatar":null},"body":"> Gesendet: Sonntag, 07. Juli 2024 um 21:54 Uhr\n> Von: \"brian m. carlson\" <sandals@crustytoothpaste.net>\n> An: github@online.ms\n> Cc: git@vger.kernel.org\n> Betreff: Re: linux git init/clone on Netapp NTFS security style volumes\n>\n> On 2024-07-06 at 19:35:30, github@online.ms wrote:\n> > Hello,\n> >  \n> > I'm trying to execute git init and git clone operations on a linux\n> > client that mounts a Netapp volume with NTFS Security Style. Meaning\n> > the client is Linux based but the filesystem is managed from Windows\n> > side - especially linux chmod operations are not permitted.\n> >  \n> > Maybe a new CLI option might be helpful to skip those chmod operations.\n> \n> I'm not surprised by this, because Windows volumes under WSL also have\n> the same problem.  However, I don't see the behaviour you describe when\n> creating a new file system with NTFS on Linux and using ntfs-3g to\n> mount with default options.  In my case, everything works just fine.\n> \n> Note that I didn't try using the old non-FUSE driver because that's\n> deprecated and I don't believe it's available anymore in Debian sid.\n> \n> What OS (including version) are you using and how are you mounting the\n> file system?\n> -- \n> brian m. carlson (they/them or he/him)\n> Toronto, Ontario, CA\n> \n\nThe 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.\nCurrently, OS is ubuntu 22.04. I'm confident that the distribution does not make a difference.\n\nFollowing section of the code should be skipped for given case.\nhttps://github.com/git/git/blob/master/config.c#L3434-L3438\n\n\t\tif (chmod(get_lock_file_path(&lock), st.st_mode & 07777) < 0) {\n\t\t\terror_errno(_(\"chmod on %s failed\"), get_lock_file_path(&lock));\n\t\t\tret = CONFIG_NO_WRITE;\n\t\t\tgoto out_free;\n\t\t}\n\nI'm looking for some advice how to best skip or catch this section.\n\nIn addition, I came across this Netapp setting which might just ignore the chmod operations without Client side failure. I haven't tested it yet.\nhttps://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/Can_I_set_UNIX_style_permissions_from_an_NFS_mount_on_an_NTFS_qtree\n\n\nThank You\n\nJosef\n\n\n"},{"id":"498322","messageId":"ZoxeQgi3RWIHUPya@tapette.crustytoothpaste.net","threadId":"61745","inReplyTo":"trinity-3d633a4a-10c6-444e-9e5c-79330941ddb6-1720457458565@3c-app-webde-bap34","subject":"Re: Aw: Re: linux git init/clone on Netapp NTFS security style volumes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-07-08T21:46:42Z","receivedAt":"2024-07-08T21:46:51Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-07-08 at 16:50:58, github@online.ms wrote:\n> 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.\n> Currently, OS is ubuntu 22.04. I'm confident that the distribution does not make a difference.\n\nOkay, then I think the answer is that your NFS server is considered to\nbe broken, and there are a variety of NFS breakages that violate POSIX\nthat we don't work around, including the very common one where\nopen(file, O_RDWR, 0444) doesn't work.\n\nI will tell you that this configuration will break a lot of other tools,\nnot just Git.  Git LFS and its testsuite will be broken; the Perl,\nPython, and Ruby testsuites will also be broken; and there's various\nother software I know of that simply will not work on such a file system\n(and a simple search turns up yet more). chmod is a really fundamental\npiece of Unix functionality, and even if you patch this in Git, you're\ngoing to see a bunch of breakage and most upstreams and distros won't\ncare.\n\n> Following section of the code should be skipped for given case.\n> https://github.com/git/git/blob/master/config.c#L3434-L3438\n> \n> \t\tif (chmod(get_lock_file_path(&lock), st.st_mode & 07777) < 0) {\n> \t\t\terror_errno(_(\"chmod on %s failed\"), get_lock_file_path(&lock));\n> \t\t\tret = CONFIG_NO_WRITE;\n> \t\t\tgoto out_free;\n> \t\t}\n> \n> I'm looking for some advice how to best skip or catch this section.\n\nWe have core.filemode, but according to the documentation, that only\ntakes into consideration the executable bit.  So I suppose you could add\na third option, \"none\" (or \"broken\"), that is the equivalent of false\nbut also means that chmod is broken altogether and shouldn't be used.\nThe documentation would need to be updated as well.\n\nSomeone else might prefer a different option for this altogether, but\nyou may not get that feedback until you send a patch.\n\n> 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.\n> 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\n\nThat might be also be a viable approach.  I don't see an option to\ndisable this functionality in the Linux NFS client, which is where I\nwould have looked.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"}]}