I think I've discovered the source of the issue. The [task](https://firefox-ci-tc.services.mozilla.com/tasks/RiTzAYC-QEOxCZjglzZ7WA) being submitted extracts a zip file to the directory `.`: ``` "mounts": [ { "format": "zip", "content": { "taskId": "X5XjPiC6TC2tpFef1H11tg", "artifact": "public/build/mozharness.zip" }, "directory": "." }, ``` The problem is that generic-worker aggressively sets recursive directory permissions for the mounted folder, and since the directory `.` is the home directory of the task user, it tries to affect the ownership of `Desktop` and directories under `Library` that upsets Big Sur (presumably this was no problem on Catalina). There are a few different options we could use to solve this issue: 1) The task could be adapted to extract the mozharness zip file to a subdirectory, and then the paths updated. 2) I think the mozharness zip already contains a top level `mozharness` directory inside the zip file, so perhaps the zip file could be changed not to include the top level `mozharness` directory, so that paths remain the same, but the directory to unzip to could be changed to `mozharness` 3) We could change the mounts feature to only try to apply permissions changes to directories, if those directories do not exist already. I suspect option 3) is the correct approach in any case, but 1) or 2) would be reasonable workarounds in the meantime. Although 3) is a pretty easy fix for generic-worker. We didn't see this issue in our testing, as we don't have tasks that extract archives to `"."`.
Bug 1673069 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I think I've discovered the source of the issue. The [task](https://firefox-ci-tc.services.mozilla.com/tasks/RiTzAYC-QEOxCZjglzZ7WA) being submitted extracts a zip file to the directory `.`: ``` "mounts": [ { "format": "zip", "content": { "taskId": "X5XjPiC6TC2tpFef1H11tg", "artifact": "public/build/mozharness.zip" }, "directory": "." }, ``` The problem is that generic-worker aggressively sets recursive directory permissions for the mounted folder, and since the directory `.` is the home directory of the task user, it tries to affect the ownership of `Desktop` and directories under `Library` that upsets Big Sur (presumably this was no problem on Catalina). ``` 2020/10/28 08:09:44 Running command: /usr/sbin/chown -R task_160389635555599:staff /Users/task_160389635555599 2020/10/28 08:09:45 Error running command: 2020/10/28 08:09:45 chown: /Users/task_160389635555599/Desktop: Operation not permitted chown: /Users/task_160389635555599/Desktop: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/CallHistoryTransactions: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/CallHistoryTransactions: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/com.apple.sharedfilelist: Operation not permitted ..... ..... ``` There are a few different options we could use to solve this issue: 1) The task could be adapted to extract the mozharness zip file to a subdirectory, and then the paths updated. 2) I think the mozharness zip already contains a top level `mozharness` directory inside the zip file, so perhaps the zip file could be changed not to include the top level `mozharness` directory, so that paths remain the same, but the directory to unzip to could be changed to `mozharness` 3) We could change the mounts feature to only try to apply permissions changes to directories, if those directories do not exist already. I suspect option 3) is the correct approach in any case, but 1) or 2) would be reasonable workarounds in the meantime. Although 3) is a pretty easy fix for generic-worker. We didn't see this issue in our testing, as we don't have tasks that extract archives to `"."`.
I think I've discovered the source of the issue. The [task](https://firefox-ci-tc.services.mozilla.com/tasks/RiTzAYC-QEOxCZjglzZ7WA) being submitted extracts a zip file to the directory `.`: ``` "mounts": [ { "format": "zip", "content": { "taskId": "X5XjPiC6TC2tpFef1H11tg", "artifact": "public/build/mozharness.zip" }, "directory": "." }, ``` The problem is that generic-worker aggressively sets recursive directory permissions for the mounted folder, and since the directory `.` is the home directory of the task user, it tries to affect the ownership of `Desktop` and directories under `Library` that upsets Big Sur (presumably this was no problem on Catalina). ``` 2020/10/28 08:09:44 Running command: /usr/sbin/chown -R task_160389635555599:staff /Users/task_160389635555599 2020/10/28 08:09:45 Error running command: 2020/10/28 08:09:45 chown: /Users/task_160389635555599/Desktop: Operation not permitted chown: /Users/task_160389635555599/Desktop: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/CallHistoryTransactions: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/CallHistoryTransactions: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/com.apple.sharedfilelist: Operation not permitted ..... ..... ``` There are a few different options we could use to solve this issue: 1) The task could be adapted to extract the mozharness zip file to a subdirectory, and then the paths updated. 2) I think the mozharness zip already contains a top level `mozharness` directory inside the zip file, so perhaps the zip file could be changed not to include the top level `mozharness` directory, so that paths remain the same, but the directory to unzip to could be changed to `mozharness` ~~3) We could change the mounts feature to only try to apply permissions changes to directories, if those directories do not exist already.~~ ~~I suspect option 3) is the correct approach in any case, but 1) or 2) would be reasonable workarounds in the meantime. Although 3) is a pretty easy fix for generic-worker.~~ We didn't see this issue in our testing, as we don't have tasks that extract archives to `"."`.
I think I've discovered the source of the issue. The [task](https://firefox-ci-tc.services.mozilla.com/tasks/RiTzAYC-QEOxCZjglzZ7WA) being submitted extracts a zip file to the directory `.`: ``` "mounts": [ { "format": "zip", "content": { "taskId": "X5XjPiC6TC2tpFef1H11tg", "artifact": "public/build/mozharness.zip" }, "directory": "." }, ``` The problem is that generic-worker aggressively sets recursive directory permissions for the mounted folder, and since the directory `.` is the home directory of the task user, it tries to affect the ownership of `Desktop` and directories under `Library` that upsets Big Sur (presumably this was no problem on Catalina). ``` 2020/10/28 08:09:44 Running command: /usr/sbin/chown -R task_160389635555599:staff /Users/task_160389635555599 2020/10/28 08:09:45 Error running command: 2020/10/28 08:09:45 chown: /Users/task_160389635555599/Desktop: Operation not permitted chown: /Users/task_160389635555599/Desktop: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/CallHistoryTransactions: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/CallHistoryTransactions: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/com.apple.sharedfilelist: Operation not permitted ..... ..... ``` There are a few different options we could use to solve this issue: 1) The task could be adapted to extract the mozharness zip file to a subdirectory, and then the paths updated. 2) I think the mozharness zip already contains a top level `mozharness` directory inside the zip file, so perhaps the zip file could be changed not to include the top level `mozharness` directory, so that paths remain the same, but the directory to unzip to could be changed to `mozharness` 3) ~~We could change the mounts feature to only try to apply permissions changes to directories, if those directories do not exist already.~~ ~~I suspect option 3) is the correct approach in any case, but 1) or 2) would be reasonable workarounds in the meantime. Although 3) is a pretty easy fix for generic-worker.~~ We didn't see this issue in our testing, as we don't have tasks that extract archives to `"."`.
I think I've discovered the source of the issue. The [task](https://firefox-ci-tc.services.mozilla.com/tasks/RiTzAYC-QEOxCZjglzZ7WA) being submitted extracts a zip file to the directory `.`: ``` "mounts": [ { "format": "zip", "content": { "taskId": "X5XjPiC6TC2tpFef1H11tg", "artifact": "public/build/mozharness.zip" }, "directory": "." }, ``` The problem is that generic-worker aggressively sets recursive directory permissions for the mounted folder, and since the directory `.` is the home directory of the task user, it tries to affect the ownership of `Desktop` and directories under `Library` that upsets Big Sur (presumably this was no problem on Catalina). ``` 2020/10/28 08:09:44 Running command: /usr/sbin/chown -R task_160389635555599:staff /Users/task_160389635555599 2020/10/28 08:09:45 Error running command: 2020/10/28 08:09:45 chown: /Users/task_160389635555599/Desktop: Operation not permitted chown: /Users/task_160389635555599/Desktop: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/CallHistoryTransactions: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/CallHistoryTransactions: Operation not permitted chown: /Users/task_160389635555599/Library/Application Support/com.apple.sharedfilelist: Operation not permitted ..... ..... ``` There are a few different options we could use to solve this issue: 1) The task could be adapted to extract the mozharness zip file to a subdirectory, and then the paths updated. 2) I think the mozharness zip already contains a top level `mozharness` directory inside the zip file, so perhaps the zip file could be changed not to include the top level `mozharness` directory, so that paths remain the same, but the directory to unzip to could be changed to `mozharness` 3) ~~We could change the mounts feature to only try to apply permissions changes to directories, if those directories do not exist already.~~ ~~I suspect option 3) is the correct approach in any case, but 1) or 2) would be reasonable workarounds in the meantime. Although 3) is a pretty easy fix for generic-worker.~~ (see comment 11) We didn't see this issue in our testing, as we don't have tasks that extract archives to `"."`.