[GH-ISSUE #82] umask CLI option doesn't handle octal umask value #47

New issue

Closed

opened 2026-03-04 01:41:31 +03:00 by kerem · 1 comment

kerem commented

2026-03-04 01:41:31 +03:00

Owner

Originally created by @tmwong2003 on GitHub (Nov 13, 2014).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/82

I ran into the issue with subdirectories in an s3 bucket not having x-ams-meta-*** headers, and therefore appearing to have d--------- permissions. The user, group members, and others could not list the subdirectories.

I followed the suggestion of setting umask=022 in issue 370 from the Google Code issues (https://code.google.com/p/s3fs/issues/detail?id=370), which forces subdirectories to have drwxr-xr-x permissions. The user and group members could then list the subdirectories, but others still could not.

It turns out that the parser code for umask values doesn't handle string representations of octal values correctly. The parser code dropped leading zeros and treated the remaining digits as base-10 integers; thus, it was treating octal 022 as base-10 22, i.e., octal 026.

The workaround is to set umask values to hexadecimal values, which the parser code does handle correctly. Thus, for 022, use 0x12.

Originally created by @tmwong2003 on GitHub (Nov 13, 2014). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/82 I ran into the issue with subdirectories in an s3 bucket not having `x-ams-meta-***` headers, and therefore appearing to have `d---------` permissions. The user, group members, and others could not list the subdirectories. I followed the suggestion of setting `umask=022` in issue 370 from the Google Code issues (https://code.google.com/p/s3fs/issues/detail?id=370), which forces subdirectories to have `drwxr-xr-x` permissions. The user and group members could then list the subdirectories, but others still could not. It turns out that the parser code for umask values doesn't handle string representations of octal values correctly. The parser code dropped leading zeros and treated the remaining digits as base-10 integers; thus, it was treating octal 022 as base-10 22, i.e., octal 026. The workaround is to set umask values to hexadecimal values, which the parser code does handle correctly. Thus, for 022, use 0x12.