No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

```const accessPoint = new awsnative.efs.AccessPoint(`${nam}influxAP`, {
        fileSystemId: efs.id,
        rootDirectory: {
                path: "influx",
                creationInfo: {
                        ownerGid: "0",
                        ownerUid: "0",
                        permissions: "700",
                },
        },
});```
efs.id is from
```const efs = new awsnative.efs.FileSystem(`${nam}-influx-pvc`, {
        encrypted: true,
        fileSystemTags: [
                {
                        key: "Name",
                        value: `${nam}-influx-pvc`,
                },
        ],
});```
${nam} is a config variable

So does anyone know why this isn't working?

tvmia

Unless there’s a specific reason to use the aws-native provider, I would be inclined to use the aws-classic provider (<https://www.pulumi.com/registry/packages/aws/api-docs/efs/>) since aws-native is in preview at this time and so you may be hitting a bug.
If there is a reason to stick with aws-native, try
creating the access point without the `creationInfo` - if it still errors out then try
```fileSystemId: efs.id.apply(id =&gt; id),```
Maybe the efs.id is not being lifted as expected.

I discovered my bug. The path: needs to start with a slash e.g. `/influx`  and not `influx` as I wrote above.

I am using both the classic and native providers. Maybe I should switch to all classic until native is 1.x but I feel like native is the future and thus have been using it where it seems to work well. I created the underlying EFS drive with native so making the AP that way seem to make sense.

I was mostly making sure you were aware of the classic provider just in case it helped. And in this case it looks like it was a typo and not a bug in the provider. So, it definitely makes sense to keep with the native provider.